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ABSTRACT 


This thesis documents the planning, design and implementation of a regional 
wide-area network connecting K-12 schools, research institutions, libraries and 
institutions of higher education throughout the Monterey Bay area of California's 
central coast. The goal of the network is to enable students and educators to have 
access to the environmental information and resources available regionally via the 
Internet, at speeds which will encourage interaction and maintain interest. The 
wide-area network design process presents numerous human and technical 
challenges. These challenges are further amplified by the need to enable educators 
to design and implement school local area networks concurrent with the wide-area 
network solution. The processes used to resolve these myriad issues and the 
resulting solutions are of direct relevance to the K-12 community as well as 
network planners, administrators and funding partners. 
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I. INTRODUCTION 


As a member of the Initiative for Information Infrastructure and Linkage 
Applications (I^LA) network design team this author participated in the design and 
implementation of a regional network, Monterey BayNet. The network connects 
kindergarten through twelfth grade (K-12) students, educators and research institutions 
throughout Monterey and Santa Cruz counties on the central California coast. 
Internetworking local area networks (LANs) over such a widely dispersed geographical 
area creates a Wide-Area Network (WAN) and presents many technical and human 
challenges. Lessons learned in solving these challenges are presented here to assist further 
expansion of Monterey BayNet, assist other K-12 schools and assist other individual 
groups building local and regional networks. 

The importance and value of documenting such efibrts can not be overemphasized. 

The technical issues associated with developing and deploying a 
national information infrastructure are far from resolved.... To a large extent, 
the National Information Infrastructure [Nil] will be a transformation and 
extension of today's computing and communications infrastructure (including, 
for example, the Internet, telephone, cable, cellular, data, and broadcast 
networks). Trends in each of these component areas are already bringing 
about a next-generation information infrastructure. Yet the outcome of these 
trends is fer from certain; the nature of the National Information Infrastructure 
that will develop is malleable. Choices will be made in industry and 
government, beginning with investments in the underlying physical 
infiustructure. Those choices will affect and be affected by many institutions 
and segments of society. [NRC, 94] 

This case study is presented as a blueprint of Monterey BayNet design and 
implementation efforts. It is primarily written for the K-12 technology mentors who are 
interested in joining or creating their own regional network. Lessons learned are also 
applicable to creating community networks and internetworking Naval Bases. This work 
is particularly valuable as an example of the success that can be achieved through the 
collaborative partnership of the educational community, research community, commerce, 
and government. 
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A. 


BACKGROUND 


In early 1994 a number of grants were funded that had been collaboratively 
planned to enable several independent organizations and volunteer groups to design and 
implement a regional wide area network (WAN) called Monterey BayNet. The initial 
Monterey Bay Regional Education Futures (MB ReEF) consortium design effort focused 
on the educational community, keeping a longer range vision of expansion to include 
partnership with commerce, tourism, and agriculture. A three-tier approach was adopted 
to match a hierarchy of service needs, expertise, and technology. Figure 1.1 shows the 
initial Monterey BayNet member sites as identified by the MB ReEF consortia for CalREN 
grant funding. 

CalREN was created by Pacific Bell (PacBell) in 1993 to fund collaborative 
projects whose applications might revolutionize the ways that individuals and 
organizations communicate and share information [PacBell, 94]. Projects are focused in 
the Education, Health Care, Community, Government, and Commercial Business areas. 
Projects are funded for a maximum of two years and connect using PacBell data 
communications technologies. Technologies available include Integrated Services Digital 
Network (ISDN), Switched Digital Service-56 (SDS-56), Switched Multimegabit Data 
Service (SMDS), Frame Relay and Asynchronous Transfer Mode (ATM) [PacBell, 95]. 

The CalREN grant "Destination Tomorrow: making connections for the ultimate 
field trip..." requested funding for Pacific Bell telecommunications service to connect 43 
regional test-bed sites [Matray, 94]. The grant was awarded 14 April 1994. Service 
installation fees and connectivity are fully funded by the CalREN grant until June 30th, 
1996. Of particular interest in the awarding of this grant is that PacBell had not previously 
planned to deploy Frame Relay service in the Monterey Bay area as early as needed by the 
grant recipiants. The collaborative strength and technical depth of the MB ReEF effort 
persuaded PacBell to advance scheduled technology deployment plans in support of the 
consortium and the community. 
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The ATM backbone pictured in Figure 1.1 is deployed independently of the 
regional Frame Relay WAN topology. Discussion of ATM technology will be limited to 
overview material for comparison with the Frame Relay technology that forms the core of 
Monterey BayNet. Integrated Services Digital Network (ISDN) connections will 
someday be implemented in Monterey BayNet where studio quality videoconferencing is 
required. A comparison of ISDN and Frame Relay technology follows which explains the 
decision of the PLA network design team to choose Frame Relay over ISDN as the initial 
core technology. 

B. MOTIVATION 

Monterey BayNet is the child of several unique parents. The Monterey Bay 
Futures Network was formed by community leaders in response to the pending closure of 
Fort Ord. This group was interested in leveraging the regions unique environment-related 
resources with advanced information technology. The FLA consortium was formed 
bringing together researchers, government, and business for the purpose creating a 
sustainable regional information infrastructure. Members of the consortia include 
Monterey Bay Aquarium Research Institute (MBARI), University of California Santa 
Cruz (UCSC), California State University Monterey Bay (CSUMB), Naval Postgraduate 
School (NFS), Cabrillo College, Pacific Bell (PacBell), Lloyd Internetworking, Monterey 
County Office of Education (MCOE), Santa Cruz County Office of Education (SCCOE), 
Monterey Peninsula Unified School District (MPUSD) and others [Bom, 95]. 

The network was envisioned as a community resource that might provide full 
access to the Internet via videoconferencing and hypermedia applications at a variety of 
bandwidth rates. The end goal is the creation of a "collaborative educational 
infrastracture around the Monterey Bay Sanctuary that will build a sustainable base and 
national model for the application of telecommunications technology in environmental 
education". [Matray, 94] "Life-long learning" and "access to informational and 
instmctional resources" are the end products of Monterey BayNet, not technology per se 
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[Matray, 94], Critical to the understanding of this project is that the technology is the 
vehicle for progress, not the end result. This thesis describes the development of that 
vehicle, which hopefully will enable the shared understanding of the region's resources. 


Three overarching and interactive elements will guide the development 
process within this seasphere of influence: high-speed data 
communications access and computer technologies are made available to 
K-14, scientific research communities, and libraries by business and 
industry partners. Based upon this access, educators, scientists, engineers, 
and technicians can work collaboratively to sort and identify relevant 
electronic data sources based on real world applications and real world 
interactions. [Matray, 94] 


Technical problems have technical solutions. The truly difficult task within the 
consortia lies with those who are developing the regional content. The content is the final 
product which Monterey BayNet seeks to access. In this light the consortia quickly 
recognized that solutions to human issues, as well as technical ones, were critical to the 
long term success of the network [I^LA, 94]. 

This problem looks just like one facing Naval Bases all around the world today. 
Local and regional data sources desire the ability to share data. The Internet model 
provides an effective low-cost solution which can be adapted to meet the needs of a Naval 
Depot, Naval Air Station or Naval Base. 


C. HOW TO USE THIS THESIS 


This thesis follows the network design team's decision points and solution rationale 
in a logical order, rather than in a chronological order. It is tailored for the non-technical 
reader, so many technical details are (necessarily) presented in overview. It is intended to 
serve as an exemplar for similar networking efforts. Recommendations on how to use this 
thesis for different individuals follow. 


5 



1 . 


Teachers and Students 


Teachers and students can use this thesis to better understand the technology 
behind the Internet. This thesis can be used to design further expansion of existing 
networks, or to design and deploy entirely new local and wide area networks. Teachers 
entering the information era can begin to develop an appreciation of the magnitude of 
Internet resources and how to manage them in the educational environment. The 
document also provides guidance in troubleshooting and managing a K-12 LAN. 

2. Policy Makers 

Security, acceptable use, liability, life-cycle management costs and standardization 
are all key issues which were faced in implementing Monterey BayNet. This thesis can be 
used to demonstrate the need for policy, and to derive a starting point for policy 
formulation. Issues faced in the development of a K-12 WAN are present across all 
networked communities. 

3. Network Builders 

As with eveiy project of any scale, some decisions were made which proved faulty. 
This thesis attempts to document them by containing a great many lessons learned. It can 
also be used to demonstrate the need for building a scalable infrastructure that supports 
future expansion through a range of user requirements. The document also can be used to 
compare the major strengths and weaknesses of emerging fast packet technologies such as 
Frame Relay, Integrated Services Digital Network (ISDN) and Switched Multimegabit 
Data Service (SMDS). 
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4. 


Network Administrators 


This thesis clearly demonstrates the need for early investment in trained 
administrators and network management. This thesis is of particular value to 
administrators who are building a new WAN. This thesis can be used to highlight why 
there needs to be early and equal emphasis placed on network management and 
administration. This thesis demonstrates this need clearly by documenting the default 
management case. Further study of these topics will appear in Wide-Area Network (WAN) 
Management: A Case Study [Trepanier, 95]. 

5. Navy Personnel 

This thesis can be used as a low-cost model for LAN and WAN connectivity in the 
Navy. It clearly demonstrates that information infrastructure installation does not require 
outsourcing for technical proficiency reasons. Individual commanders can perform most 
or all work required to connect to the Internet. This thesis can also be used to identify 
existing hardware which can be reused to lower installation costs. In today's environment 
of reduced budgets and transition toward commercial off-the-shelf (COTS) solutions, this 
project can be used as an exemplar. The issues involved at every level of design of this 
K-12 network have parallels within network design at DoD. 

D. SUMMARY 


Monterey BayNet is a regional WAN designed and constructed by a unique 
collaborative volunteer effort. Monterey BayNet is focused on the K-12 community, 
linking educators, students and researchers to the Internet with PacBell Frame Relay 
service. This thesis presents the major design and implementation issues faced by the 
network design team. This thesis was written primarily for the K-12 educator but parallels 
issues faced in every WAN environment. 
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n. RELATED WORK 


The scope of Monterey BayNet project is well beyond the bounds of any single 
thesis. An overview of this diverse research effort appears in "Networked Ocean Science 
Research and Education, Monterey Bay California" [Brutzman, 95], emphasizing 
connectivity, content, access, and applications. Many of the issues which are covered in 
this thesis wiU require re-examination as technology advances and user needs evolve. 
Other related efforts complement and overlap this thesis. They include: 


• Realizing the Information Future: The Internet and Beyond [NRC, 94] - Report 
of the National Research Council (NRC) NRENAISSANCE Committee. A critical 
examination of architectural and deployment issues relating to the creation of a National 
Information Infrastructure (NB). This report describes past and recommended future 
government involvement with the 'superhighway' initiatives forming the Nil. 

• RLA Net Design White Paper [I^LA, 94] - The white paper is the initial focal 
document behind several Monterey Bay region initiatives. It provides necessary 
background information on the development of the I^LA, its mission and goals. Included 
are an executive summary, profiles of member institutions, tiger team profiles, publicly 
accessible information resources and team member contact information. 


• Building the Future: K-12 Network Technology Planning Guide - The 
California Department of Education's statewide networking standards [CDE, 94], This 
document was carefully designed to provide broad guidance to K-12 institutions in the 
deployment of information technology. The guide clearly defines the need for Internet 

access throughout the K-12 community and the educational benefits that access will yield 
to teachers, students and society. 
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• The fLA Network: Physical Configuration Team Project [Trepanier et al., 95] - 
A report created by a team of Naval Postgraduate School students which descnbe the 
efforts of a Tier I Monterey BayNet site in technology transfer to Tier II and III sites. The 
team’s effort is particularly successful in the area of equipment configuration and end-user 

training. 


• Using the Multicast Backbone (MBone)for Distance Learning: A Case Study 
A master's thesis that documents the viability and impact of distance learning using the 
MBone [Emswiler, 95]. The case study documents the learning points denved from the 
successful world-wide multicast of the Dr. Richard Hamming course "Learning to Learn." 

The research provided complete course coverage, world-wide, for a full academic quarter. 
This is the first documented attempt of extending traditional education methods using the 

MBone. 

• Wide-Area Network (WAN) Management: A Case Study - A master's thesis 
documenting the need and design requirements for a Monterey BayNet Network 
Information Center (NIC) and Network Operations Center (NOC) [Trepamer, 95]. 
Wide-Area Network (WAN) Management: A Case Study will provide a logical extension 
from this thesis, recommending solutions to problem areas identified in Monterey BayNet 
administration and management. 

Numerous additional books and on-line resources exist for connecting to the 
Internet. Notable entries include; 

• Entering the World-Wide Web (WWW): A Guide to Cyberspace [Hughes, 94]. 

• The Web Empowerment Book [Abraham, 94]. 

• WWW Unleashed \DQ(x,vi:k)QT, 95]. 

• The Whole Internet [Krol, 93]. 

• World Link An Internet Guide for Educators, Parents, and Students [Joseph, 95]. 
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The Internet Engineering Task Force (IETF) is a volunteer group that "provides a 
forum for working groups to coordinate technical developments of new protocols. Its 
most important function is "the development and selection of standards within the Internet 
protocol suite." [Malkin, 94] A component of the IETF is the Internet School 
Networking (ISN) working group. The ISN was chartered to "address issues related to 
the connection of primary and secondary schools worldwide to the Internet." [Sellers, 95] 
The group maintains a general discussion mailing list isn-wg@nasa.gov. To subscribe to 
the mailing list send e-mail to listmanager@nasa.gov with the message subscribe isn-wg in 
the body of the message, leave the subject line blank. The group has issued several IETF 
Request For Comments (RFC) pertaining directly to K-12 Internet connectivity. They 
include: 


• RFC 1578 FYI on Questions and Answers: Answers to Commonly Asked 
'Primary and Secondary School Internet User’ Questions [Sellers, 94]. 

• RFC 1709 K-12 Internetworking Guidelines [Gargano, 94]. 

• RFC 1746 Ways to Define User Expectations [Manning, 94]. 

On-line information pertaining to the Monterey BayNet effort can be found at the 
following Universal Resource Locators (URL): 

• The LLA home page provides access to LLA summary information, proposals 
and anonymous ftp server. In addition it has many useful links to information sources on 
commerce, digital libraries, education, environment, government. National Information 
Infi-astructure (NO), networking and telecommunications. Available at 

ftp://taurus. cs. nps. navy. mil/pub/iSla/iSla. html. 

• The Learning About Monterey Bay (LAMBAY) home page provides 
information about the collaborative education and research surrounding Monterey Bay. 
Particular emphasis is placed upon the region's diverse habitats, including the unusual 
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marine life of the deep sea canyon [Atkinson, 95]. Links are provided to local education, 
research, libraries, and government sites. Available at http://lcmbay.cse.ucsc.edu/mh. 

• The Monterey Bay Regional Education Futures (MBReEF) Consortium home 
page provides links to information sources throughout the Monterey Bay region. Included 
are links referenced by region, environment, education, research, libraries, government, 
commerce, tourism and culture. Available at http://www.ucsc.edu/mbay-region. 

• The Real-time Environmental Infomiation Network & Analysis System 
(REINAS) home page provides access to both real-time and retrospective regional scale 
environmental science via the REINAS distributed database environment. The REINAS 
project is a cooperative effort of Monterey Bay region meteorological and oceanographic 
scientists from the Baskin Center of the University of California Santa Cruz (UCSC), 

Naval Postgraduate School (NPS), Monterey Bay Aquarium Research Institute (MBARI), 
and the National Oceanic and Atmospheric Administration Center for Ocean Analysis and 
Prediction (NOAA/COAP). The REINAS Project is funded by the Office of Naval 
Research under a University of California Santa Cruz Research Initiative [Rosen, 95]. 
Available at http://csl.cse.ucsc.edu/reinas.html. 

The amount of literature related to Monterey BayNet is considerable. The 
Monterey Bay region hosts numerous research initiatives, all of which will utilize 
Monterey BayNet as a vehicle for regional information dissemination. From the K-12 
student perspective Monterey BayNet is the access mechanism which unlocks regional and 
global content. The references listed in this section provide a generous set of starting 
points for understanding the magnitude and scope of the interrelated Monterey BayNet 
projects. 
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in. PROBLEM STATEMENT 


The fundamental problem examined in this thesis is how to cost-efFectively and 
fiilly connect educators, students and researchers to the Internet. More specifically, since 
a predefined group of participants and technologies exist, the problem is "how do you 
cost- effectively connect the 43 Monterey BayNet sites using PacBell offered services"? 

In each case the term cost-effective was used as a precondition to the required 
connection solution. This should be further clarified to reflect the financial constraints 
placed upon the client sites. Educational funding in California schools is such that every 
effort to save financial resources, without affecting upward scalability, must be exercised. 
The final solution must be the lowest cost solution which meets end user needs. California 
funding for technology in education was $2.35 per student in 1993, compared to $153.20 
per student in Connecticut [Cradler, 1994]. In 1994 California was ranked last among 
states in a survey of student-to-computer ratios [QED, 94]. 

"What are the end user needs?" The primary end user in Monterey BayNet is the 
K-12 teacher or student. A method of determining what the end user expects from an 
information system is required in order to meet those expectations. This problem is 
compounded by the fact that present technology implementation in the Monterey Bay 
region's education system is so badly out of date. End users cannot be expected to 
accurately express needs without some knowledge of available systems. A baseline set of 
end user requirements must be established using available data that can later be evaluated 
and updated. 

The main question is how to facilitate technology transfer to individual schools. 
The design, procurement and fielding of Local Area Network (LAN) technology is 
required in order to capitalize upon Wide Area Networking (WAN) benefits. The 
internetworking of schools creates a regional network but does not necessarily provide 
access to Internet data and information outside of that region. The next question then 
becomes "how do you build local area networks and connect them to form a wide area 
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network with Internet access?" Again the single overriding constraint is educational 
finance (taxpayer dollars). 

Provided that these questions can be answered and implemented, the question that 
immediately follows is how to support the network and the end users. An information 
system must be supported in order to remain effective. Network faults will need to be 
diagnosed and repaired. Users will require training and technical support for their Local 
Area Networks (LANs). Typically solutions are manpower intensive. Where is the trade¬ 
off between short-term investment costs and long-term management costs. In short, "how 
do you ensure that Monterey BayNet will succeed"? 

The scope of the Monterey BayNet project is so large that resolution of many 
important issues has been delayed in favor of achieving short-term goals. First among 
these goals has been getting schools, teachers and students on-line. We are successfully 
achieving that goal. This thesis will answer three research questions, and lay the 
foundation for a fourth. 

• What are the end user needs? 

• How do you cost-effectively build Local Area Networks (LANs)? 

• How do you cost-effectively connect the 43 Monterey BayNet sites using 
PacBell services and Internet access in a Wide-Area Network (WAN)? 

• How do you ensure that Monterey BayNet will be sustainable? 

Follow-on research [Trepanier, 95] wiU address wide-area network management issues in 
greater detail. 


14 


IV. SOFTWARE APPLICATION SELECTION 


A. INTRODUCTION 

This chapter explains the importance of understanding end user information system 
requirements. End users will interact with the applications running on their networks, not 
with the technology on their desks. The ULA net design team spent time learning what 
the end user needed, determining which software would provide that functionality, and 
finally building software distributions of public domain programs that meet all user 
requirements for network-based education. Monterey BayNet's most important end users 
are teachers and students. Monterey BayNet also considers scientific researchers and the 
general public as important end users. 


B. END USER REQUIREMENTS 


A primary key to effective system development and implementation is the correct 
assessment of end user requirements [Whitten, 89]. The net design team derived end-user 
requirements from needs assessments in the supporting grant documentation [Matray, 94], 
and also from direct interaction with end users [Hudson, 94]. Requirements are 
summarized in Figure 4.1 and explanations follow. 


• Full Internet access 

• Videoconferencing capability 

• Hypermedia technology: text, graphics, PostScript documents, archived 
audio and video 

• Low cost 

• Rapid network response to end user requests 


Figure 4.1 End-user requirements. 
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Full access on the Internet is defined as "a permanent (full-time) Internet 
attachment running Transmission Control Protocol/Intemet Protocol (TCP/IP), primarily 
appropriate for allowing the Internet Community to access application servers, operated 
by Internet providers" [Crocker, 95], TCP/IP are the sets of software protocols (rules) 
which enable remote computers to directly connect to networks which are interconnected 
throughout the Internet [CDE, 94], For example. Trumpet Winsock is TCP/IP software 
for Windows compliant platforms, and is freely available via File Transfer Protocol (FTP) 
download frova.ftp.cica.indiana.edu in directory ftp/pub/pc/win3Avinsock/twsk20b.zip. 
Winsock shareware requiring a $25 registration fee after evaluation [Tattam, 94], 
Similarly, MacTUP is proprietary TCP/IP software for Macintosh platforms. The easiest 
way to obtain MacTCP is through the purchase of The Internet Starter Kit for the 
Macintosh (currently $29.95) at many bookstores [Engst, 94], MacTCP is also provided 
with the Macintosh operating system 7.5. 

Videoconferencing across the Internet is possible using a number of differing 
applications. The net design team is currently conducting research with the Multicast 
Backbone (MBone) which allows one-to-many communications [Macedonia, Brutzman, 
94][Emswiler, 95]. MBone software is not yet available for Windows and Macintosh 
platforms but is expected. An interim videoconferencing tool (also free) is CU-SeeMe 
[Cogger, 94]. CU-SeeMe allows point-to-point connections between both Macintosh and 
Windows platforms. 

Interactive technology refers to World-Wide Web (WWW) graphical browsers 
such Mosaic [NCSA, 94] and Netscape [NCC, 95]. These tools allow easy access to 
hypertext and multimedia information. Widespread availability of these effective and user- 
friendly tools has revolutionized use of the Internet. 

Members of the net design team met to identify a suite of publicly available 
applications which would meet end user needs in both the Macintosh and Windows 
environment (Appendices A, B). Choosing and evaluating applications from publicly 
available freeware and shareware ensured that software cost was minimal. The final 
software and corresponding functionality reconimendations are shown in Table 4.1. 
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Interestingly, these choices are a superset of what is recommended for National 
Information Infrastructure compliance (Nil) [NRC, 94], 



WINDOWS 

MACINTOSH 

FUNCTIONALITY 

APPLICATION 

APPLICATION 

Graphical Web Browser 

Netscape 

Netscape 

Mail Client 

Eudora 

Eudora 

Usenet Newsreader 

WinVNNNTP 

Newswatcher 

File Transfer Protocol Tool 

WSJFTP 

Fetch 

Virtual Terminal Access 

Trmptel 

NCSA Telnet 

Gopher 

WinGopher 

TurboGopher 

Image viewer/converter 

Lview 

GIF converter 

Sound viewer 

Wham 

ScmndMachine 

Video file viewer 

Quicktime 

Sparkle 

Data compression / decompression tool 

WinZip 

Stuffit Expander 

Shared whiteboard application 

NCSA Collage 

NCSA Collage 

SGML application 

HotMetal 

BBEdit 

Video Conferencing 

CU-SeeMe 

CU-SeeMe 

Virus Protection 

F-Prot 

Disinfectant 

Network Diagnostics 

Ping 

MacTCP Watcher 

PDF file viewer 

Adobe Acrobat 

Adobe Acrobat 

PostScript file viewer 

GhostScript 

GhostScript 


Table 4.1. Software functionality provided in final software distribution package. 

Rapid network response, the final end user requirement, has two contributing 
elements. The first element is the data exchange rate (bandwidth) between the end user 
network and the Internet provider. This will be discussed in greater detail in Chapter VI. 
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The second element is the ability of the local computer to process the data provided from 
the Internet. To prevent poor performance and wasted investment the net design team 
established baseline personal computer hardware requirements for network access (Table 
4.2). Platforms which do not meet or exceed the baseline will probably not perform well 
enough to justify the expense of a Network Interface Card (NIC). 


Macintosh Personal Computer 

IBM Compatible Personal Computer 

Operating System 7.0 or better 

Operating System Shell 

Microsoft Windows 3.0 or better 

Minimum 68030 processor 

Minimum 386 processor 

Minimum 8MB RAM 

Minimum 8MB RAM 

Minimum 250 MB Hard Drive 

Minimum 340 MB Hard Drive 

Ethernet Capable 

Ethernet Capable 

Monitor - 256 color minimum 

Monitor- 256 color minimum 


Table 4.2. Minimum recommended PC hardware for K-12 schools [Herbst, 95]. 

The network design team also evaluated IBM’s OS/2 Warp as a possible operating 
system shell for 386-based personal computers [IBM, 95]. OS/2 is technically superior to 
Windows in a number of ways. However, the team decided to focus on Windows as the 
default environment due to wider use and familiarity among the schools. A recommended 
area for future work is to build an 05/2-based software distribution as an alternative for 
schools. A further alternative yet to be evaluated is Linux, the freeware UNIX operating 
system. Since OS/2 and Linux can coreside with Windows, further opportunities for 
improved functionality at low cost are expected. 
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C. TECHNOLOGY PUSH-PULL 


The end users in this case study are teachers and students. They are being placed 
in the position of responding to technology, rather than guiding the integration of 
technology. Funding to support connectivity is based upon a CalREN telecommunications 
access grant which expires in June 1996 [Matray, 94], To achieve maximum benefit from 
the funding in a timely manner, some decisions have been made based upon assumptions 
that are not yet proven in practice. The "push" has been to quickly get the technology in 
the field so that we can use the connectivity and learn from our errors. All of the 
applications selected for the initial implementation will be reviewed after the end user has 
had the opportunity to evaluate their effectiveness in the educational environment. Thus 
the "pull" will be intellectual market forces and feedback from end users which produces 
an optimal software configuration. Enabling end users to upgrade and improve the 
recommended software build will make this process sustainable and allow continual 
improvement. Figure 4.2 provides definitions of technology push and pull. 


• Technology Push - Educators responding to sudden technology introduction. 

• Technology Pull - Educators requesting new technology based upon need. 


Figure 4.2 Definition of technology push and pull. 


D. ESTABLISHHiG REALISTIC END USER EXPECTATIONS 

The technology "push" described in the previous section has often created end user 
resistance and confusion. Efforts to ease the strain of technology "push" have focused 
primarily on training. A pilot training session, "On-Ramp to the Super Efighway" 

[Davis, 94], allowed 40 teachers the opportunity to receive "hands-on" training at the 
Naval Postgraduate School. The pilot session success led to a full scale "Virtual Night" 
[Sanders, 95] where 200 educators attended application demonstration sessions and later 
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had the opportunity to explore the Internet on their own. Educators with no previous 
exposure to the technology needed almost zero assistance beyond initial login procedures. 
These sessions, in addition to net design team software demonstrations on January 20th 
and 27th hopefully have contributed to ease the introduction of technology. Clearly they 
have helped to clarify end user expectations and create end user demand or "pull." Further 
hands-on demonstration events are planned in conjunction with the SIGGRAPH 
conference [Brutzman, 95] and other events. 

E. SUMMARY 

This chapter described the process by which the net design team developed the 
current end user requirements and the software suite to match. Installing the software and 
maintaining it will be discussed in Chapter VII. End user needs will change over time. A 
process similar to that discussed in this chapter will be required to recognize and manage 
changes to the software suite. Additional research is needed to determine the optimal use 
of technology in the K-12 community. The net design team has highlighted multi-media 
and videoconferencing applications. Further research can focus the requirements by 
determining, for instance, the system response time required to maintain student attention 
and interaction. It is strongly recommended that the effectiveness of the initial software 
load be evaluated by the end of the first year. 

The most exciting and encouraging aspect of this entire project is that these are not 
merely theoretical problems. Real teachers and real students are beginning to use the 
technology to work on real problems. We expect to learn very interesting results. 
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V. LOCAL AREA NETWORK (LAN) DESIGN 


A. INTRODUCTION 


"What is a LAN? How do I build a LAN?" This chapter will provide all of the 
technical and background information required to build a sustainable local area network. 
The goal is to design a LAN which meets immediate user needs, and can be later expanded 
as user needs evolve. There is a great deal of information involved, but the planning and 
building a LAN itself is straightforward and appears in Figure 5.1. 


• Appoint a Network Manager. 

• Evaluate existing wire and cable paths for possible reuse. 

• Make a site drawing which shows desired computer locations. 

• Draw network using topology guidelines in this chapter and following 
existing cable paths. 

• Derive equipment requirements from the site plan. 

• Procure equipment (Appendix E). 

• Install. 


Figure 5.1 Local Area Network (LAN) planning methodology. 


B. LOCAL AREA NETWORK (LAN) DEFINITION 

A common misconception is that a LAN is the sharing of data, whereas in fact a 
LAN is merely the transmission path upon which sharing may occur. The shared medium 
is the physical infrastructure or cabling which makes up the backbone of every LAN. Here 
is one definition; 


The IEEE 802 LAN is a shared medium peer-to-peer 
communications network that broadcasts information for all stations to 
receive. The LAN enables stations to communicate directly using a 
common physical medium on a point-to-point basis. The network is 
generally owned, used, and operated by a single organization. [IEEE, 90a] 
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The idea of a shared medium is a key concept when planning a LAN. The 
infrastructure is the physical wiring of the LAN, over which all network devices 
communicate. A properly designed infrastructure can be flexible enough to support 
current and future networking needs. While cable itself is relatively inexpensive, the labor 
involved in installing cable or modifying existing cable runs can be daunting. Cable and 
hardware infrastructure quickly become the primary limiting factors in most LANs. 

C. IEEE 802.3 CSMA/CD: ETHERNET 

Every networked device requires some method of gaining access to the LAN 
shared medium. The IEEE 802.3 Medium Access Control (MAC) method is Carrier 
Sense Multiple Access with Collision Detection (CSMA/CD). CSMA/CD is a contention 
technique which allows devices to compete for medium access. The CSMA/CD function 
is physically performed by each device's Network Interface Card (NIC), commonly called 
an Ethernet card. 

A common analogy for describing low-level CSMA/CD functionality is that of a 
dinner conversation in the dark. Each guest wants to speak but can not see the other 
guests. In order to communicate a guest must listen for silence, and then start speaking. 
This is analogous to the carrier sense mode. Multiple Access refers to the fact that every 
guest can contend for transmission time. Occasionally two guests will start speaking 
simultaneously and then have to stop. This is the collision detection mode. When a 
collision is sensed both guests will stop speaking, listen for silence for an independently 
random time, and resume talking. 

The nature of the MAC method requires that there be some additional constraints 
placed upon the LAN. To continue the analogy you can imagine that there would be a 
limit to how long the dinner table might be, or how many guests might easily converse. 
These limits are summarized in Table 5.1. Fortunately the specifics of how devices 
interact over a shared medium are ordinarily transparent to end users. Knowledge of 
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low-level network fiinctionality is not necessary for users who only want to run network 
applications. 


Ethernet 

Type 

Transmission 

Medium 

Data Rate 

(Mbps) 

Maximum 

Segment 

Length (m) 

Maximum 

Nodes per 

Segment 

10BASE5 

Coaxial Cable 

(.4 in dia.) 

10 

500 

100 

10BASE2 

Coaxial Cable 

(.25 in dia.) 

10 

185 

30 

lOBASE-T 

Unshielded 

Twisted Pair 

10 

100 

2 


Table 5.1. IEEE 802.3 physical layer specifications [IEEE90b]. 


10BASE5 Ethernet (commonly known as "ThickNet") uses standard baseband 
coaxial cable as its shared medium. It is not commonly found in use due to high 
installation and maintenance cost. ThickNet design guidelines are beyond the scope of 
this thesis. 10BASE2 Ethernet, also known as "ThinNet" or "Thin Coax" offers many of 
the advantages of ThickNet with lower cost and easier installation. Bus topology makes 
10BASE2 ideally suited for use in network backbone applications. 10BASE2 Ethernet 
uses .25 inch diameter Coax (RG-58A/U or RG-58 C/U) cable as the shared medium. 
lOBASE-T Ethernet uses Unshielded Twisted Pair (UTP) wire in star physical topology as 
the shared medium. Most existing telephone-based customer premises wiring plants 
resemble star physical topology. Most schools in Monterey BayNet use lOBASE-T. 
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D. SHARED MEDHJM SELECTION 


In addition to the design restrictions discussed above, the type of shared medium 
chosen will impose growth limitations upon the LAN. It is important to understand that 
the 802.3 Ethernet standard enables LAN communications at data exchange rates up to 
10Mbps. 100BASE-T is currently under development and will enable data exchange rates 
of up to 100Mbps, but only if the shared medium (i.e. the cable) will support 100Mbps. 
Media transmission rates are summarized in Table 5.2. 



Maximum 

Approximate 

Cable 


cost per foot 

Media 

rate (Mbps) 

(1995 pricing) 

RG-58 

10 

$0.26 

CAT-1 UTP 

1 

$0.03 

CAT-2 UTP 

4 

$ 0.05 

CAT-3 UTP 

16 

$0.10 

CAT-4 UTP 

20 

$0.16 

CAT-5 UTP 

100 

$0.18 


Table 5.2. Cable media transmission rates and approximate cost. 

Category 1 and 2 UTP are low-data-rate cables which can not support 802.3 
Ethernet. Since labor is the primary cost in cable installation, it is recommended that any 
new cable installations use category 5 UTP for future growth. Nevertheless, there is rarely 
any technical need to upgrade category 3 or 4 wiring already in place. Category 5 UTP 
upgrade will be required only if 100Mbps Ethernet evolves as a mature technology and 
user needs dictate faster LAN transmission rates. Installation of category 5 UTP where 
new cabling is required allows maximum flexibility for fiiture expected requirements. 
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E. SITE EVALUATION AND END USER BUY-IN 


The final asset which must be considered in LAN design is the physical site itself. 

A simple map or blueprint of the building or buildings is essential, as is an understanding 
of existing cable paths (conduits) connecting these structures. If such a map is not 
available it will be necessary to create one by tracing, hand-over-hand, the cabling in place. 
A detailed discussion of local building codes can ordinarily be found at the local city 
planner's office. In general it may be assumed that cabling connecting buildings or running 
through an exposed outdoors environment needs to be contained in a conduit. The local 
physical plant engineer or building manager will likely be knowledgeable about additional 
local regulations. 

A single point of contact on site must be appointed as the network manager. This 
person will need to maintain full knowledge of the premises wiring and network 
configuration. Initially thisjob will not require much time. As network grows and 
becomes more complex this may evolve into a sizable task. Without a single individual 
who is interested and involved, a growing LAN will quickly be at the mercy of paid 
consultants. The simple knowledge of how an infrastructure is connected can save many 
hours of consultant fees. 

Since the LAN is going to be a part of the larger Internet it will eventually have to 
be connected to a Wide-Area Network (WAN). The equipment required to connect to the 
WAN is discussed in the next chapter. A logical starting point for LAN design is to begin 
at the service provider's Minimum Point Of Entry (MPOE). This is the first telephone 
panel inside the site premises after the telephone pole. PacBell identifies the MPOE with a 
green "MPOE" tag. Existing telephone services are already configured in a star physical 
topology. It may be possible to use existing excess capacity in the locally distributed 
telephone wiring to service your LAN. For this to occur the following must be 
determined to be true: 
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• Existing wire is 24-gauge, unshielded, twisted-pair, solid-conductor. 

Category 3 or better. 

• 2 unused twisted pairs are available to each end location. 

• The twisted pairs are free of splices. 

• The maximum length of the 2 twisted pairs is 100 meters. 

Given a good understanding of existing physical infrastructure, LAN designers are 
able to determine where additional cable needs to be installed. The next two sections 
contain guidelines for planning a network topology to meet user needs. It is important to 
plan for future expansion throughout the entire facility, not just to meet immediate needs. 

F. lOBASE-T DESIGN GUIDELINES 

lOBASE-T network design is based upon star topology (Figure 5.2). lOBASE-T 
operates over 2 pairs of wire, one pair used for receive data signals and the other for 
transmit data signals. The wire must conform to EIA/TIA Category 3 (or greater) wire 
specifications and follow the EIA/TIA-568B wiring scheme (Appendix C) [EIA/TIA-568]. 

Every UTP segment is connected to exactly two nodes and segment length is 
limited to 100m (328ft). The term "star" comes from the physical topology created when 
a number of nodes are connected using lOBASE-T repeaters, also called hubs or 
concentrators (Figure 5.3). Hubs allow multiple node inputs to be concentrated into a 
single output. Recall that the Ethernet MAC method is CSMA/CD. Thus the job of the 
hub is merely to amplify an incoming signal from any node and rebroadcast it to all other 
nodes. 

There are limitations on the number of repeaters and cable segments allowed 
between any two stations on the network. The "5-4-3 Rule" states that "there may be 
no more than five (5) repeated segments, nor more than four (4) repeaters between any 
two nodes, and of the five cable segments, only three (3) may be populated" 

[IEEE, 90b]. The term "populated" refers to a segment which connects two hubs. 
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Figure 5.2 Conceptual lOBASE-T star topology. 



Figure 5.3 Physical lOBASE-T star topology. 
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Commercial hubs are available with up to 48 ports. In designing the LAN ensure that 
purchased hubs have more capacity then is currently needed. This will allow for future 
expansion and greater flexibility. The Ethernet theoretical maximum is 1024 nodes per 
lOBASE-T network [IEEE, 90b]. 

G. 10BASE2 DESIGN GUIDELINES 

10BASE2 network design is based upon bus topology. On a bus or backbone a 
single coaxial cable acts as the shared medium for all nodes. Signals broadcast from a 
node travel in both directions the length of the bus and can be received by all nodes 
[Stallings, 94]. The coaxial cable is actually composed of 2 to 29 cable lengths, each no 
shorter then .5m (20in). Cable lengths are joined at each node with male BNC 'T' 
connectors (Figure 5.4). Note that each'T' connector is attached directly to a node's NIC. 
By definition the distance between each node and the bus can not exceed 4cm (the depth 
of the BNC'T' connector) [IEEE, 90b]. 



RG-58 

Coax 

Male BNC I 
Connector^) 

BNCT' ic 

BNC 50 Ohm 
Terminator 


Female BNC 
Connector ^ 


NETWORK 

IWreRPCE 

CARD(MC) 



Figure 5.4 BNC "T" connection to node. 

Each fiill segment can be no longer then 185m (606ft) and must be terminated at 
each fax end with a 50 ohm BNC terminator to provide circuit continuity. Each single 
segment can contain no more than 30 nodes and 2 terminators (Figure 5.5). 
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Figure 5.5 Single segment 10BASE2 network. 

Multiple 10BASE2 segments can be joined using repeaters (Figure 5.6). The 
”5-4-3" rule discussed in the previous section applies to 10BASE2 networks as well. A 
maximum of four repeaters are allowable creating an overall maximum 10BASE2 span of 
925m and 150 nodes [IEEE, 90b]. 



Figure 5.6 Two segment 10BASE2 network. 


H. lOBASE-T / 10BASE2 COMPARISON 

10BASE2 network installation is attractive in that it saves the initial expense of 
purchasing multiple hubs. It is relatively easy to install and removing a node does not 
affect the rest of the network. lOBASE-T is slightly more expensive initially, but it is far 
more expandable and cost-effective in the long term. If Category 5 UTP wiring is in 
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place, an upgrade from lOBASE-T to 100BASE-T is possible. The 10BASE2 
infrastructure cannot be upgraded to support 100Mbps without installing new cabling. 

Beyond installation cost is the cost of preventive and corrective maintenance. A 
malfunctioning node on a 10BASE2 bus can affect all other devices connected to the bus. 
Troubleshooting can be difficult and time consuming. The usual method of fault isolation 
involves disconnecting devices one at a time until the faulty node is discovered. In 
comparison, a lOBASE-T network node which malfunctions is easily found and isolated 
from the rest of the network. Indication lights on the lOBASE-T hubs make it a simple 
matter to troubleshoot large networks. Appendix D contains a variety of example LAN 
designs implemented in the performance of this thesis. 

1. EQUIPMENT SELECTION 

There are numerous vendors that sell IEEE 802.3 Ethernet products. It is 
important to standardize the equipment used in a network. Standardization of Monterey 
BayNet occurred throughout the two counties, not just within individual schools. This 
will allow all of the end users to become familiar with the strengths and oddities of a single 
product, rather than confuse them with multiple differences between platforms. Appendix 
E describes the Monterey BayNet equipment recommendations. These recommendations 
serve two purposes. They simplify the management of the WAN, and they make 
troubleshooting easier for the individual members of the WAN. 

1. Simple Networit Management Protocol (SNMP) 

"Intelligent" networking devices are those devices which are able to operate as 
Simple Network Management Protocol (SNMP) agents [Case, 90]. Devices which can 
have this ability include; 

• Hubs 

• Routers 
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• Network Interface Cards 

• Peripheral Devices 

• Channel Service Unit (CSU)/Digital Service Unit 

SNMP compatibility greatly enhances a network administrator's ability to monitor 
and correct problem areas within the LAN. SNMP agents report their status periodically 
and upon request to a management station. The management station in turn can send 
orders back to the agent, correcting errors detected in the LAN. 

Maintenance of a SNMP management station is often beyond the ability of LAN 
managers. That responsibility can be passed up to the WAN manager. If the WAN 
manager acts as the management station for all attached LANs, economies of scale may be 
achieved which make overall network management cost effective and improve system 
reliability. The additional cost of SNMP capability is nontrivial but SNMP compatibility is 
an essential component of LAN design. It is less expensive to purchase SNMP capability 
"up front" than to upgrade equipment in place. These issues will be examined in fiirther 
detail in "Wide-Area Network (WAN) Management: A Case Study" [Ir&pSimQt, 95]. A 
new proposed standard for SNMP Version 2 which extends current SNMP capabilities is 
discussed in RFC 1441 [Case, 93], 

2. Proprietary Technology 

The IEEE 802.3 standards provide minimum technical guidelines which many 
manufactures have been able to exceed. Some of these products allow communication 
over greater distances or through lower grade media. These products may be useful to 
provide technical solutions for situations where distance constraints .or media restrictions 
prevent compliance with 802.3 specifications. Never the less, the LAN planner must 
avoid deviation from minimum specifications whenever possible. The purchase of 
proprietary non-standard equipment usually creates a situation where the LAN manager 
limits future upgrade possibilities and commits to a sole source of proprietary hardware. 
Such a situation is extremely undesirable. 
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3. 


LAN Operating Systems 


A LAN operating system is required if users desire the added functionality of being 
able to share a single copy of a "networked" software application throughout the LAN. 
This makes a great deal of sense in that a single site license for X machines is normally 
cheaper than X copies of that software. This approach also frees hard drive disk space on 
individual computers, usually by putting the single copy of site-licensed software on a file 
server. 

Each individual computer has its associated operating system, ordinarily MS-DOS 
6.1 or better on IBM platforms, and System 7.1 or better in the Macintosh world. A LAN 
operating system is software, normally resident on a file server, which enables LAN clients 
to share software applications resident on that file server [Long, 93], Macintosh 
AppleTalk [Apple, 95] znd Microsoft Windows for Workgroups [Microsoft, 95] are two 
examples of LAN operating systems which enable shared applications in a single operating 
system environment without the additional expense of a dedicated file server. In a LAN 
environment with mixed operating systems, a more robust LAN operating system such as 
Novell Netware will be required to enable shared applications across multiple platforms. 
Configuration of Novell Netware or equivalent normally requires the service of a Certified 
Network Engineer (CNE). 

J. LAN DESIGN SUMMARY 

The focus of this chapter has been on building a LAN with the supporting 
infrastructure to make it expandable for fiiture growth. lOBASE-T is the preferred 
solution. The most cost-effective implementation utilizes existing excess telephone lines 
reaching to the classrooms. Excess lines are not always available and often new cable is 
required. The high dollar item in cable installation is the labor involved in installing the 
cable. The California Department of Education (CDE) recommends pulling coax for cable 
television at the same time that Category 5 UTP is pulled for the LAN [CDE, 94]. The 
actual wiring of the RJ-45 ports and 8-position modular plugs requires more patience than 
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skill. A crimping tool and lOBASE-T tester are required items and can be found at any 
major electronics outlet. 

Figure 5.7 outlines some of the more common pitfalls encountered on the way to 
successful implementation. Avoid them! Chapter VI vrill discuss the equipment required 
to connect a LAN to the WAN. In LAN design, the WAN connection is "just another 
node" which happens to be at the MPOE. Do not forget to include the WAN connection 
in the site plan. 


• Do not violate 802.3 specifications - system degradation will result from 
crosstalk, lost packets and excess collisions. 

• Do not use splices, the 100 meter rule is actually expressed in decibel loss. 
Splices degrade signal strength. 

• Do not mix and match equipment, pick a single standard product. 

• Avoid proprietary solutions. 

• Label all wires and maintain a detailed record of the network. 

• Verify that equipment ordered has the desired connectors. Inexpensive hubs 
often require external transceivers for AUI connections. 

• Test every connection during and after installation. 

• Verify that there are only two terminators in every 10BASE2 segment. 


Figure 5.7 Correcting common mistakes in LAN installation. 


Many opportunities exist to continue research in the K-12 LAN design area. Fiber 
Distributed Data Interface (FDDI) backbone topology is becoming increasingly cost 
efifective and may provide a migration path for schools with widely distributed campuses. 
Another LAN technology which deserves examination in the K-12 community is the 
emerging wireless LAN. While still more expensive than wired LANs, wireless 
technology may provide a migration path for schools with unique needs. Finally the likely 
deregulation of the telecommunications industry may soon narrow the dividing line 
between telephone provider and cable television provider. Technology exists which can 
carry both television and LAN data traffic over existing cable industry coax. As these 
technologies continue to evolve they need to be examined to determine if they are 
cost-efiFective and scalable in the K-12 community. 
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VI. WIDE AREA NETWORK (WAN) DESIGN 


This chapter reviews the telecommunications services available for WAN 
connectivity, and the net design team's justification for selection of Frame Relay. Internet 
service provider selection is discussed briefly, as well as the equipment selection and the 
group purchase technique used. After reviewing the supporting decisions a coherent 
WAN design is presented. The chapter concludes with an overview of the Monterey 
BayNet ff addressing schema, autonomous system (AS) registration and domain name 
registration procedures. 

A. WAN DESIGN PROCESS INTRODUCTION 


Figure 6.1 attempts to provide an ordered view of WAN design. The network 
design team experience in creating Monterey BayNet has shown that most of these 
decision points happened almost simultaneously. The decisions are highly interdependent, 
making the designation of network administrators critical. In the case of Monterey 
BayNet the network administrators are the County Offices of Educations (COEs). The 
participating LANs are 43 CalREN member sites. 


• Assign Network Administrator 

• Identify Participating LANs 

• Evaluate and select communications mode 

• Select Internet provider 

• Select required hardware 

• Model WAN topology 

• Assign IP addresses 

• Assign domain names 

• Determine routing and routed protocols 

• Implement 


Figure 6.1 WAN planning steps. 
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The following sections provide background information and describe the decisions 
of the network design team. In most cases the network design team considered a range of 
options. There are also options which may not have been considered or that this author 
has chosen not to include. The success of the process at an individual site lies in the 
network administrator's careful consideration of all options in cooperation with the 
Internet provider and hardware manufacturers. The success of the process regionally has 
been due to the open and collaborative sharing of questions, problems and answers. 
Individual sites might have proceeded more quickly if they pursued independent 
approaches, but it is highly unlikely that any uncoordinated LANAVAN plan might be 
more reliable, robust and well-suited to all Monterey BayNet members. 

B. TECHNOLOGY OVERVIEW 

There have been a number of advances in computer network reliability and digital 
technology in the past decade. These advances have made extremely high rates of data 
transfer (bandwidth) possible in a WAN environment. The net design team reviewed four 
service options available through PacBell for WAN connectivity. The criterion for 
selection included adequate data transfer rates for hypermedia, the potential to sustain 
videoconferencing via MBone, ease of upward transition when demand increases in the 
future, and long-term access costs to the end user after the CalREN grant expires. 

1. Asynchronous Transfer Mode (ATM) 

ATM, also called Cell Relay, is an ultra-high-speed switching and transmission 
fabric which is intended to form the high-performance portion of the Monterey BayNet. 
The ATM portion of BayNet will be distinct from lower-bandwidth portions of BayNet 
[PLA, 94]. PacBell's ATM service offering will initially operate from 45 Mbps (DS-3 
lines) to 155 Mbps (OC-3 lines), evolving to the gigabit per second (Gbps) range (billion 
bits per second) [PacBell, 95]. ATM differs from Frame Relay through the use of fixed 
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length packets called cells. The reduction achieved in individual cell overhead allows 
greatly improved data transmission rates [Stallings, 94], A good introductory reference to 
ATM IS Asynchronous Transfer Mode Networks: Performance Issues [Onvural, 94]. 


2. Switched Multimegabit Data Service (SMDS) 

Switched Multimegabit Data Service (SMDS) is a public, cell-switched service 
offering high-performance data transmission [Sprague, 93]. Pacific Bell's current SMDS 
offering include transmission rates from 1.5Mbps (T1 line) to 45Mbps (T3 line) 

[PacBell, 95]. SMDS differs from ATM through its use of the public switched network. 
The net design team did not recommend the use of SMDS because 1.5Mbps to 45 Mbps 
connectivity to schools appeared excessive and expensive. Table 6.1 lists PacBell tariff 
rates for single LATA SMDS service [PacBell, 95]. 


Data Rate 

Installation 

HBSi 

1.17 Mbps 

$1009 

$775 

4 Mbps 

$7300 

$5700 

10 Mbps 

$7300 

$6700 

16 Mbps 

$7300 

$7200 

25 Mbps 

$7300 

$7700 

34Mbps 

$7300 

$8200 


Table 6.1. SMDS intra-LATA service tariff [PacBell, 95] 


3. Integrated Services Digital Network (ISDN) 

ISDN is a standardized telecommunications network architecture providing 
multi-channel, integrated end-to-end connectivity. ISDN allows the high-speed 
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transmission of digital information through a single customer interface, whether the 
content is voice, data, video or graphic images [PacBell, 95], Basic Rate ISDN (BRI) 
provides two full 56 Kbps unrestricted "B" channels for voice or data and one 16 Kbps 
"D" channel for signalling and data, on a single line. To the end user ISDN service will act 
"just like" telephone service. The service is digital so there is no need for a modem, but 
terminal adapter (TA) hardware is required and "calls" are still placed linking the user to 
the target host. 

Pacific Bell has three rate structures for BRI ISDN service: SDS, Centrex, and 
Home. SDS pricing is the rate structure which would apply for most schools attempting to 
connect to a nearby County Office of Education (COE). ISDN, like telephone service, has 
usage-based pricing and may incur long-distance charges depending upon the location of 
the caller and destination. Local usage is charged at the rate of $0.04 for the initial call 
and then $0.01 for each minute per "B" channel [PacBell, 95]. Table 6.2 lists the SDS 
ISDN charges. The actual monthly cost of an ISDN connection may be highly variable 
due to usage and long distance charges. 



Installation 

Monthly 

Usage (100 Hours) 

Two 56 Kbps "B" Channels 

$70.75 

$24.82 

~$120 + 


Table 6.2. PacBell SDS ISDN rate. [PacBell, 95] 


For technical reasons Primary Rate ISDN (PRI) appears to be the best ISDN 
choice for schools. PRI provides scalable upgrades in capacity from 128 Kbps all the way 
to 1.5 Mbps (Tl) at 64 Kbps increments (i.e. "fractional Tl"). Basic Rate ISDN (BRI) is 
unacceptable since the 128Kbps bandwidth limit is too low, and since BRI equipment is 
generally incompatible with PRI equipment. 

Long-term use of ISDN by schools will require a predictable and affordable rate 
structure for connectivity charges. Interoperability concerns will hopefully be fixed when 
equipment vendors implement Multi-link PPP protocol [Sklower et al., 94], an open 
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standard that will ensure compatibility and avoid unacceptable proprietary software 
restrictions. Until these two problems are fixed, ISDN is not a practical solution for 
providing school connectivity. Figure 6.2 summarizes the impediments that prevented the 
net design team from recommending ISDN for school use; 


• Basic Rate Interface (BRI) ISDN is unacceptable due to low bandwidth with 
no compatible upgrade path. 

• Current high cost of Primary Rate ISDN is out of reach for schools. 

• Vendor hardware solutions are proprietary and not interoperable. Multilink 
PPP may resolve this, but has not been implemented [Sklower et al., 94], 


Figure 6.2 Deficiencies preventing endorsement of ISDN use in Monterey BayNet. 


4. Frame Relay Bearer Service 

Frame Relay bearer service is a connection-oriented, virtual circuit service. 
PacBell's current Frame Relay service offers transmission rates from 56 Kbps to 1.544 
Mbps, increasing in 56Kbps increments [PacBell, 95]. The Frame Relay protocol achieves 
increases in speed beyond its predecessor X.25 transport protocol by performing error 
correction only at the origin and destination [Sprague, 93]. Frame Relay is a data link 
layer protocol which can operate over ISDN or Frame Relay bearer service, although 
Frame Relay protocol implementations over ISDN are not currently offered by Pacific Bell 
[Chen, 89][Sprague, 93]. For the purposes of this thesis. Frame Relay will imply Frame 
Relay protocol over Frame Relay bearer service. 

Frame Relay is offered as a flat-rate, distance-insensitive service. These attributes 
make Frame Relay an ideal service for connecting regional LANs, particularly in the 
education sector. Flat-rate pricing (Table 6.3) leaves no budgetary doubt for school 
boards in planning their information technology budget. Distance insensitivity assures that 
there are no down-stream long-distance charges to be applied on top of the flat rate. 
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Data Rate 

Installation 

Monthly 

Monthly (2 PVC) 

56 Kbps 

$1005 

$125 

$140 

128 Kbps 

$1009 

$325 

$340 

384 Kbps 

$1009 

$575 

$590 

1.544 Mbps 

$1009 

$675 

$690 


Table 6.3. Frame Relay service flat rate tariff. [PacBell, 95] 

C. SELECTION JUSTIFICATION FOR FRAME RELAY 

The network design team selected Frame Relay as the WAN connectivity service 
because it offered greater access speeds, economy, and a clear transition path for 
increased bandwidth. The selection was not intended to rule out ISDN usage in Monterey 
BayNet. ISDN has some advantages over Frame Relay in home dial-in access and in 
studio quality videoconferencing. Several sites are proceeding with the installation of both 
Frame Relay WAN connectivity and ISDN lines for comparison. 

1. Access 

The ability to use high-bandwidth Internet applications like Netscape, Mosaic and 
the MBone tools have been a primary driver of the network design. Ordinarily the 
minimum acceptable bandwidth for MBone is 128Kbps [Macedonia, 94]. PacBell BRI 
ISDN is limited to 112 Kbps [PacBell, 95]. PacBell Frame Relay services range from 
56Kbps through 1.5Mbps, making high-bandwidth access feasible. 

A second consideration to the access equation is the bandwidth of the connection 
from the County Office of Education (COE) to the Internet provider. Bottlenecks can 
occur in a purely BRI ISDN-based WAN because all lines out of the COE can be the same 
size as the line between the Internet Provider and the COE. In the case of Monterey 
BayNet, full T-1 Frame Relay service to the COE greatly reduces the likelihood of 
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congestion. The methodology for designing this topology will be presented later in this 
chapter. 

2. Economy 

At the site level ISDN initially seems like the clear price leader over Frame Relay. 
Equipment costs for both technologies are similar. The difference becomes clear when 
usage rates and long distance charges are estimated. Frame Relay costs are time and 
distance insensitive. Monthly basic rate ISDN charges, without long distance charges, 
exceed the 128Kbps Frame Relay charges at approximately 250 hours of usage. In a 
network environment 250 monthly hours is quite possible, particularly if the site wants to 
operate a server that is accessible via the Internet around the clock. 

At the county level the economic distinctions are even clearer. An ISDN-based 
WAN requires an ISDN line for each site connecting at the county office. Twenty BRI 
lines with 100 hours of average usage would cost $2896.40 monthly, compared to T-1 
access at only $960 per month ($690 per month + $15 for each additional DLCI) [PacBell, 
95]. 

The cost of a router which can connect 20 BRI lines is significantly greater than 
the cost of a Frame Relay router supporting any number of virtual circuits. Further 
savings result because the Frame Relay-based WAN needs hardware for only one physical 
WAN connection, compared to 20 in the ISDN topology. The benefit is greater simplicity, 
lower router costs, lower communications hardware costs, and lower line costs 
[Lloyd, 94]. 

3. Transition to Higher Bandwidths 

Multiple ISDN B' channels can be linked to increase bandwidth using dewces 
called inverse multiplexers. "There are (currently) no good nonproprietary ways to 
combine the two 64Kbps bearer (B') chaimels into a single logical 128Kbps channel" 
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[Lloyd, 94]. The current proprietary solutions which do exist are not compatible across 
manufacturers. ISDN Internet providers resolve the compatibility issue by strictly 
specifying the access hardware which is known to work with their system. 

In contrast to ISDN, Frame Relay hardware specifications are widely accepted and 
interoperable products are offered by numerous vendors. PacBell supports dedicated 
56Kbps Frame Relay bearer service over advanced digital network (ADN) lines. 

Fractional T-1 lines (128Kbps through 1.5Mbps) are provided by High Capacity Digital 
Service (HiCap). A T-1 line is composed of twenty four 64Kbps channels. A channel 
service unit (CSU) is used to aggregate channels, offering a range of service from 
128Kbps through 1.5Mbps. No additional hardware is required to increase bandwidth 
beyond 128Kbps. The network design team does not recommend 56Kbps Frame Relay 
service because it will not support nominal MBone transmission rates and future upgrades 
to 128Kbps or above will require the purchase of new CSU hardware and installation of a 
new HiCap line. 

D. FRAME RELAY NETWORK CONNECTION DETAILS 

Frame Relay is a data link layer, packet switched, multiplexed data networking 
technology. The Frame Relay network is based upon the routing of frames (Figure 6.3) 
by a data link control identifier (DLCI) value [Stallings, 94]. Information of variable 
length is encapsulated in the frame, to be opened at the destination. Routing is 
accomplished by forwarding fi'ames across a permanent virtual circuit (PVC) to the 
location specified by the DLCI connection table. The table is maintained and updated by 
the Frame Relay switch. Figure 6.4 demonstrates how each site has a physical connection, 
yet can support multiple PVCs. 
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Information 


FCS 


Flag 



Figure 6.4 Example Permanent Virtual Circuits (PVCs) in the Frame Relay cloud. 


The Frame Relay multiplexing function enables the creation of the multiple PVCs. 
Each end of a PVC is assigned a unique IP address, creating the interface between ff and 
DLCI assignment. Each PVC is assigned a committed information rate (CIR), i.e. a 
"worst case" data exchange rate. 
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The physical equipment needed on site to connect a LAN to a Frame Relay line is 
detailed in Figure 6.5. PacBell brings the High Capacity Digital Service (HiCap) to the 
MPOE and installs the Network Interface Unit (NIU). The port on the NIU has been 
disconnected so it is necessary to install an external RJ-48 connector. This can be installed 
by PacBell for a small charge or provided and installed by the user [PacBell, 95]. The 
RJ-48 does not have to be physically present at the MPOE. If the RJ-48 is not going to be 
installed at the MPOE then it is strongly recommended that PacBell do the installation. 

The demarcation line (also shown in Figure 6.5) is where PacBell's responsibility for 
maintenance ends. The demarcation line is determined by who installs the RJ-48. The 
physical wiring of the RJ-48 connector to the output of the Network Interface Unit (NIU) 


is detailed in Appendix F. 
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Figure 6.5 Equipment required to connect a LAN to the Frame Relay cloud. 


An eight-position modular plug to eight-position modular plug is provided with the 
CSU for connection to the RJ-48. Connection to the router will depend upon the CSU 
and router specifications. The RJ-48, CSU and router must located together. Both the 
CSU and Router will require 1 lOVAC from a standard electrical outlet. It is strongly 
recommended that all network hardware power supplies be protected with surge 
suppression devices. Surge suppression devices must have adequate amperage capacity 
(typically 30 to 40 amps) and meet National Electrical Safety Code (NESC) specifications 
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[ANSI, 1993], Consideration might be given to the purchase of an Uninterruptible Power 
Supply (UPS). A UPS conditions power to filter out power spikes, surges and provide 
back-up power in the event of a brown-out or black-out. Surge suppressors merely 
protect the internal power supplies of connected devices by acting like an additional circuit 
breaker. The decision to purchase a UPS is a business decision, not a technical one. A 
UPS is recommended where the data that is being processed has value exceeding the cost 
of the UPS. 

E. INTERNET PROVIDER SELECTION 

Monterey BayNet spans two PacBell Local Access Transport Areas (LATAs). In 
this case the LATA boundaries generally follow county borders, with Santa Cruz in LATA 
1 and Monterey in LATA 8 (Figure 6.6). 



Figure 6.6 California LATAs [PacBell, 95]. 
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PacBell is a local telecommunications provider. Telecommunication regulations 
prohibit local providers from crossing LATA boundaries. Only long distance providers 
such as AT&T, MCI or Sprint are authorized to connect local providers across LATA 
boundaries. Thus PacBell was initially prevented from providing dual LATA service. 
Despite this impediment the CalREN trust agreed to award a grant to the Monterey 
BayNet consortium. This presented Monterey BayNet with four options for connecting 
the two COEs. 

• Establish a microwave link between two sites spanning the LATA boundary. 

• Request regulatory relief from the California legislature. 

• Hire a long distance provider to connect the COEs across the LATA boundary. 

• Select an Internet provider which already has a inter-LATA agreement. 

The microwave link is an attractive and technically feasible solution for connecting 
data networks. Use of the link might remove the need to hire a long distance provider, but 
setup cost is substantial. A proposal was discussed at length with California Senate 
Majority Leader Henry Mello that would allow PacBell an exemption in the case of 
Monterey BayNet inter-LATA traffic. The legislation was viewed favorably but 
alternative solutions were found which avoided the necessity of lengthy legislative effort. 
To avoid the additional expense of an inter-LATA bridge the network design team built 
two WANs which are virtually connected by the Internet. Internet provider selection was 
thus narrowed to providers having a presence in both LATAs and an inter-LATA 
agreement with a long distance carrier. 

The Internet provider selection process was based primarily upon cost. After 
much debate the network design team recognized that, reliability issues aside, Internet 
access ought to be viewed as a commodity. Most Internet providers offer a range of 
services. Full service generally implies that the provider will include the cost of required 
hardware and data circuits as part of the activation and installation fees. Additionally the 
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Internet provider often assigns the Class C IP addresses for use by connected sites and 
provides 24-hour network monitoring and problem resolution to the site level [Baer, 94], 

Monterey BayNet opted to install and maintain all member site connections. This 
decision was primarily driven by cost to the end user. WAN management for each county 
is, by default, the responsibility of the respective COE. Each COE hosts an Internet server 
and functions as the domain name server for the member sites. This configuration matches 
the recommendations of the California Department of Education's Network Technology 
Planning Guide [CDE, 94]. An alternative solution might have been the out-sourcing of 
installation and management functions to an independent contractor or an Internet 
provider. Monterey BayNet further reduced the cost of Internet access by locally 
designing, requesting and managing assigned IP address space and WAN coimectivity 
[Trepanier, 95]. California State University Network (CSUnet) was contracted as the 
Internet provider. LATA 1 connectivity in Santa Cruz County to the CSUnet backbone is 
available through the Frame Relay cloud to San Francisco State University (SFSU) and 
LATA 8 connectivity in Monterey County is through CSU Monterey Bay (CSUMB). 
CSUnet's long distance carrier is SprintNet, creating the essential inter-LATA bridge 
required to connect the two COEs. 

F. HARDWARE SELECTION 

The physical management of hardware across the WAN is made much simpler by 
brand-name standardization. Note that this is not an interoperability issue but rather a 
network management sanity issue. Standardization allows end users to pool common 
resources and develop accepted fault isolation patterns. It also presents the opportunity 
for greater manufacturer discounts through group purchase. Coordinating a group 
purchase throughout multiple school district budgets is not trivial. The Monterey County 
Office of Education (MCOE) acted as central agent for the group purchase of DSUs and 
routers throughout Monterey BayNet. The network design team in conjunction with the 
Internet provider (CSUnet) played an advisory role in equipment selection for Monterey 
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BayNet. The equipment selected and corresponding functionality are described below. 
Selection was based upon cost, interoperability, reliability, reputation, and ease of use. 

1. Channel Service Unit (CSU) Selection 

The CSU acts to synchronize the frames being output from the router with the 
proper channels on the T-1 line. A T-1 line consists of 24 channels, each with a 
bandwidth of 64Kbps. A 128Kbps site uses channels 1 and 2, while a 384Kbps site uses 
channels 1 through 6. The CSU is configured by the user at the site. Increasing 
bandwidth requires only a telephone call to PacBell to order the increased line speed and 
Committed Information Rate (CIR). Locally the only modification required is a 
corresponding adjustment the CSU hardware settings. 

Two different CSUs are used in Monterey BayNet. Those sites opting for 56Kbps 
ADN service install mAdtran 56/64 digital service unit (DSU). Configuration is 
completed by manipulating switches on the rear of the unit. Those sites installing a T-1 
line will be using the Adtran T-1 service unit (TSU). Configuration is accomplished 
through a series of menu selections. Appendix G details the configuration settings for both 
devices. A eight-position modular plug to eight-position modular plug silver satin flat 
cable is provided with each device for connection to the RJ-48. 

2. Router Selection 

The net design team selected the Cisco 2500 family of routers for use by Monterey 
BayNet. The 2500 series offers a range of technology options to end user sites. The 
Cisco 2501 is currently the low price leader. A single LAN router, the Cisco 2501 is 
capable of meeting the needs of most of our sites. The Cisco 2514 provides dual LAN 
capacity for an additional investment of $350 [Cisco, 95]. The Cisco 2514 is 
recommended as an entry level router. The Cisco 2511 provides a single LAN 
connection and 16 asynchronous ports for dial-in access. An option for non-member sites 
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in the BayNet region is the Cisco 25031, an ISDN router which can be upgraded to Frame 
Relay functionality. The 25031 provides a transition path for schools outside of CalREN 
who desire to connect to commercial Internet providers using free ISDN services offered 
by the Education First grant [PacBell, 94], 

A V.35 male to female 34-pin connector is required to connect the CSU and the 
router. The cable is not provided with the router. All Cisco 2500 routers require external 
transceivers to connect the LAN to the router's Attachment Unit Interface (AUI) port. A 
sample router configuration script is provided in Appendix H. 

3. Web Server Selection 

The centralized Internet server for each COE is the Lloyd Internetworking 
Cyberstation. Most servers which have the ability to scale to the size of the Monterey 
BayNet require UNIX operating system capabilities. The Lloyd Internetworking 
Cyberstation is a Sun SPARC workstation with Solaris 2.3 operating system and a variety 
of specially configured software [Lloyd, 95]. It was selected because it offers a graphical 
user interface (GUI) over the operating system which makes network administration 
possible without UNIX experience. Additional bundled services include POP2, POP3, 
IMAP, pine, elm, WWW server, xmosaic. Gopher server, gopher client, FTP server and 
WHOIS++ server. The Cyberstation acts as the Domain Name Service (DNS) server, 
news server, mail server and proxy server for all member sites who require the service. 
This provides a major cost savings to the end users but is not a long term solution. "A 
very small district can get away with centralized servers and a medium sized district can 
get away with it for a while, but ultimately the services need to be at the school" [Lloyd, 
94]. It is an excellent way for new administrators to learn how to manage network 
accounts. It is expected that a variety of low-cost server configurations will become 
available. As servers migrate into schools and districts hardware and software 
standardization will reduce administrative overhead. This is a good area for future 
implementation work. 
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G. WAN TOPOLOGY DESIGN 


The PVC topology evolving from the decisions of the network design team is 
similar to Figure 6.7. Frames from member sites are transiting the Frame Relay cloud to 
the COE and then through the Frame Relay cloud again to the Internet. This simple 
design works well and has the advantage of placing the COE is in a position to filter 
traffic. It has the distinct disadvantage of creating a potential single point of failure (i.e. 
the COE server). An alternative design is allow access from the school to both the COE 
and the Internet provider directly. 


Schooly 
SchooKV- 
School 




*.CSUnet 

(Internet) 


Figure 6.7 County Office of Education (COE)-centric WAN design with 
a potential single point of failure at the COE. 


Figure 6.8 demonstrates a modified design that reduces the traffic navigating the 
Frame Relay cloud and eliminates the single point of failure. The loss of the COE 
serverwould not affect the school's ability to access the Internet, nor would the loss of 
CSUnet affect the ability of the sites to communicate with their respective COE's. 

The network design team created a compromise of the two designs. The COEs 
determined that the ability of the COE to filter inappropriate traffic for the K-8 community 
was an fitting and necessary role. K-8 schools will not have direct Internet access PVCs. 
System availability was considered more vital than proper use censorship at the high 
school level, where dual PVCs will be implemented. The final PVC topology is presented 
in graphical form in Appendix I. 
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Figure 6.8 Multiple PVC WAN design. 


Each PVC consists of two IP addresses which map both ends of a DLCI. The 
technique for accomplishing this is called "subnet masking" and is described in the next 
section. Figure 6.9 shows the map of DLCI 906 connecting Monterey High School's 
physical address of205.155.36.0 with MCOE's physical address of205.155.43.0. Recall 
that the DLCI number is issued from PacBell and is associated with a CIR. The sum of all 
CIRs is not allowed to exceed approximately 200% of the physical line capacity 
[Bellamy, 95]. Appendix J is PacBell's Monterey BayNet Frame Relay DLCI/CIR matrix. 



Figure 6.9 Example Data Link Control Identifier (DLCI) mapping. 
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H. DLCI SUBNET MASKING 


IP addresses are written in dotted decimal format. 205.155.36.7 is the address for 
a single node at Monterey High. An IP address is 32 bits in length and composed of 4 
segments. Each segment of an address space is 8 bits in length. In decimal notation each 
8-bit segment equates to a number between 0 and 255. By convention the specific values 
0 and 255 are reserved, leaving 1 through 254 available for use in addressing [Lynch, 93]. 

A Class C address is the block of254 addresses available in an address of the 
format W.X. Y.O, where W, X and Y are the unique identifier segments to that LAN. 

Every Monterey BayNet site is issued a Class C block as their physical address space. 
Monterey High's Class C address is 205.155.36.Z, allowing them to assign up to 254 
unique IP addresses to their nodes (205.155.36.1 through 205.155.36.254). Monterey 
BayNet convention assigns W.X. Y. 1 to the site router, and W.X. Y.2 to the Internet server 
(if present). LAN address space subnetting is neither required nor desired. Monterey 
BayNet's Internet provider (CSUnet) has been expressly requested that sites not subnet the 
LAN class C address blocks assigned. Additional class C address blocks will be issued 
upon request if more that 254 nodes are required. 

DLCI's are specific to Frame Relay WANs. DLCI's pair together two IP addresses 
to map the ends of the PVC. Rather than waste hundreds of Class C addresses a method 
was devised to subnet a single Class C address. 255 base 10 converted to base 2 binary is 
11111111. Zero in binary is 00000000. In subnet masking the process used varies the 
final octet to derive multiple host-pairs. Monterey BayNet DLCIs use a subnet mask of 
255.255.255.252. 252 in binary is 11111100. This convention tells computers that the 
first 6 bits of the final octet are the subnet address, and the final two bits are the unique 
host. Table 6.4 demonstrates how this creates 63 unique host-pairs within a single Class C 
address space, of which 61 are usable for DLCIs. Appendix I shows all Monterey BayNet 
DLCI assignments and the IP mapping of the DLCIs. 
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1 . 


DOMAIN NAME SERVICE 


Each site has a unique physical address issued from the block of Class C addresses 
provided by the Internet provider [Gerich, 93], An alternative method of obtaining a 
block of addresses is to request them directly from InterNIC registration services. 
Appendix K provides the template for requesting IP address space from InterNIC. 

People have a difficult time recalling numbers. 205.155.36.Z is not intuitively 
recognized as Monterey High School. Contrast 205.155.36.0 with a domain name of 
mhs.monterey.kl2.ca.us. The casual observer can presume that it is a K-12 high school 
acronym from Monterey, California, United States. This system of linking physical 
addresses to names is known as domain name service [Postel, 94]. All K-12 schools are 
required to register under the US domain [Copper, 93], RFC-1480 and RFC-1591 
describe DNS registration and naming conventions. Monterey BayNet and the net design 
tiger team worked with the COEs to develop an acceptable DNS for member sites. The 
default name server for all schools is the COE Cyberstation. Appendix L is the DNS for 
Monterey BayNet. Appendix M is the InterNIC registration services DNS registration 
template. 

J. ROUTING DECISIONS 

The final planning event before connecting LANs to the WAN is the 
consideration of which routing protocol to use, and what routed protocols to allow. 
Routed protocols are protocols that are routed through a network. Internet Protocol (IP), 
AppleTalk, and NetWare (IPX) are some of the common routed protocols operating on 
LANs throughout Monterey BayNet. Monterey BayNet is initially allowing only IP traffic 
to be routed over the WAN. This decision increases security by removing the threat of 
LAN intrusion by outsiders. Hackers outside of Monterey BayNet can not easily access 
information from Monterey BayNet hosts unless that information is specifically contained 
on an Internet server. The decision to route IP only also significantly reduces the 
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administrative overhead of managing multiple routed protocols and eliminates many 
possible failure modes. 


SUBNET 

HOST 

IP ADDRESS 

DLCI 

COMMENT 

000000 

00 

198.189.239.0 

* 

* By convention neither host nor subnet 

000000 

01 

198.189.239.1 

* 

can contain all zeros or all ones 

000000 

10 

198.189.239.2 

* 


000000 

11 

198.189.239.3 

* 


000001 

00 

198.189.239.4 

* 


000001 

01 

198.189.239.5 

902 

This is the first unique host address pair 

000001 

10 

198.189.239.6 

902 

DLCI 902 links NPS with MCOE 

000001 

11 

198.189.239.7 

* 


000010 

00 

198.189.239.8 

* 


000010 

01 

198.189.239.9 

903 

This is the second unique host address pair 

000010 

10 

198.189.239.10 

903 

DLCI 903 links Seaside with MCOE 

000010 

11 

198.189.239.11 

* 


000011 

00 

198.189.239.12 

* 


000011 

01 

198.189.239.13 

904 

This is the third unique host address pair 

000011 

10 

198.189.239.14 

904 

DLCI 904 links MBTEC with MCOE 

000011 

11 

198.189.239.15 

HI 

...continues thru 198.189.239.254 


Table 6.4. DLCI addressing with subnet mask 255.255.255.252. 

The routing protocol is the set of rules that the router uses in forwarding traffic 
across the WAN. Three routing protocols were considered in detail: Routing Information 
Protocol (RIP), Interior Gateway Routing Protocol (IGRP) and Open Shortest Path First 
(OSPF) . To ensure interoperability across the WAN the Internet provider again played a 
large role in the final decision process. 
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1. 


Routing Information Protocol (RIP) 


RIP maintains a set of routing tables in each router. The tables indicate the path to 
a destination host and the "distance" (i.e. number of intermediary routers between the two 
points) to that host. RIP maintains only the shortest route to a destination. As the "best" 
paths change the revised table is sent as an update message to neighboring routers. Each 
router receiving an update message revises its tables. On a limited scale network RIP is 
effective and easy to implement. As the network grows the tables become burdensome 
and update messages consume significantly greater bandwidth [Stallings, 94]. RIP is an 
old protocol and its use is considered detrimental by many Internet experts. 

2. Interior Gateway Routing Protocol (IGRP) 

IGRP is a distance vector interior-gateway protocol (IGP). IGPs use an 
Autonomous System number (AS) to identify members of a unique WAN. Distance 
vector routing protocols call for each router to send all or a portion of its routing table in 
a routing update message at regular intervals to each of its neighboring routers in the 
network [Stallings, 94]. As routing information proliferates through the network, routers 
can calculate distances to all nodes within the AS. 

3. Open Shortest Path First (OSPF) 

OSPF is a open standard link-state routing protocol [Moy, 94] based on the 
Shortest Path First (SPF) algorithm [Dijkstra, 59]. OSPF sends link-state advertisements 
(LSAs) to all other routers within the same AS. As OSPF routers accumulate link state 
information, they use the SPF algorithm to calculate the shortest path to each node 
[Stallings, 94], 
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4. 


Selection and Implications 


OSPF was initially targeted as the routing protocol for Monterey BayNet because 
it can provide the most effective use of bandwidth. However, difBculty implementing 
OSPF on the Cisco routers during configuration training caused a reversal of policy. 

An earlier recommendation fi'om CSUnet was to use OSPF within 
our network. However, the Cisco engineers found some ugly side-effects 
in Cisco's implementation of OSPF and Frame Relay that would increase 
the complexity of the addressing in our network. CSUnet now 
recommends, with Cisco's concurrence, that we use IGRP within the 
Monterey BayNet. [Taylor, 95] 

Two final configuration parameters were established. The Logical Management 
Interface (LMI) defines the protocol for communication between a Frame Relay switch 
and a specific router interface. Monterey BayNet adopted the use of ANSI Logical 
Management Interface, standard T1.617 Annex D. 

The Cisco implementation of IGRP requires the use of an AS number [Cisco, 95]. 
"Registering for an Autonomous System Number implies that you plan to implement one 
or more gateways and use them to connect networks in the Internet." [InterNIC, 94] A 
gateway is a method of connecting other WANs via the Monterey BayNet host 
[Sprague, 93]. Monterey BayNet does not currently operate any WAN gateways. To 
fulfill the requirement for an AS in the Cisco routers Monterey BayNet arbitrarily assigned 
the AS number 10 in Santa Cruz, and 11 in Monterey. Using an unregistered AS number 
will not cause problems since AS numbers, unlike their IP number counterparts, are 
transparent to end systems. Excerpts from the InterNIC AS registration template are 
provided for reference in Appendix N. The current version of the template is maintained 
at ftp://rs. intemic.net/templates/asn-template. txt. 
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K. WAN DESIGN PROCESS SUMMARY 


To the non-technical observer the task of designing a WAN seems overwhelming. 
Monterey BayNet was successfully designed by the cooperative pooling of knowledge, 
experience and needs. Few members in the network design team had extensive network 
backgrounds. None had the breadth of knowledge needed to answer all questions, nor 
was any such person ever located. All had the desire and drive to ask all the right 
questions and search for the right answers. This team process has been a critical 
component in successfully identifying and overcoming the many hurdles involved in 
designing and implementing LANs and WANs . 

Following the model outlined at the start of this chapter (Figure 6.1) the network 
design team selected Frame Relay bearer service as its communications mode. It received 
multiple bids for Internet access and selected CSUnet as the Internet provider. Working in 
cooperation with CSUnet and PacBell the network design team selected the WAN 
hardware and initiated group purchases to maximize savings. 

With the above decisions the creation of a model topology was relatively simple. 
The topology models demonstrated strengths and weaknesses which were evaluated and 
capitalized upon. BP addresses were assigned to PacBell's DLCIs based upon the topology 
created, and a workable CIR matrix was agreed upon with PacBell. Unique site BP 
addresses were assigned and linked to domdn names registered within the US domain 
name system. Finally the routing and routed protocols were evaluated and agreed upon, 
creating the need for additional registration of two autonomous system numbers. 

Monterey BayNet as designed above has created a simple-to-implement, reliable 
regional network. There has been no opportunity yet to evaluate the design following 
implementation. To date it has met all expectations. Undoubtedly there are bound to be 
numerous nuances which were not considered or not anticipated. Traffic patterns will be 
analyzed to verify the design topology. At some point the inter-LATA issue may have to 
be re-addressed. Much of the work of network management and administration has only 
just begun, even as expansion plans are surfacing. Persistence and perseverance helped us 
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find technical solutions for all technical problems and people solutions for all people 
problems. The same collaborative spirit which designed Monterey BayNet will continue 
to shape its evolution. 
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Vn. IMPLEMENTATION RESULTS 


A. IMPLEMENTATION INTRODUCTION 

On March 24, 1995 Seaside High School became the first Monterey BayNet site 
on-line. To date 25 of 43 sites are on-line and installation eflForts continue. May 12, 1995 
marked the next milestone with the first point-to-point videoconference between two sites 
using CU-SeeMe [Herbst, 95][Cogger, 95]. 

The implementation phase began concurrently with the design phases. Configuration 
"tiger" teams fi'om Cabrillo College and the Naval Postgraduate School began conducting 
site inspections in November 1994 [Bigelow, 94]. The net design team recognized that the 
end users understanding of their role was critical to success. Implementation has been 
conducted in three steps. 

1) Initial site inspection with PacBell and configuration team. 

2) Informal follow-up of on-site technical, timing and procurement issues. 

3) PacBell Frame Relay installation and tiger team configuration. 

This chapter will highlight the configuration team's implementation process and the issues 
faced at the site and WAN management levels. 

B. INITIAL SITE INSPECTIONS 

Initial site inspections called "walk-throughs" proved to be of critical importance in 
the implementation of Monterey BayNet. The format was a scheduled meeting between site 
personnel, PacBell Frame Relay installers, and configuration team personnel. In most cases 
this was the first opportunity for end users to ask technical questions and begin to 
understand their roles and responsibilities. 

The first task in the walk-through process is for PacBell to establish the location of 
the MPOE and verify that sufficient lines are present to the MPOE for Frame Relay 
installation. California schools are generally over twenty years old and the MPOE is not 
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always obvious. In one case it was in an building no longer used by the school, on the other 
side of the football field. If the MPOE is not in a position close to where router will be 
installed, it is recommended that PacBell be consulted on establishing a secondary MPOE or 
extending the NIU to the router location. The location where the router and CSU/DSU will 
be installed will require sufficient space for either wall mounting of the devices, or 
installation of a shelf where the devices can sit. The Cisco routers come with brackets 
which allow them to be easily mounted flat on the wall. If a shelf is used ensure that a strap 
is attached to secure the devices to the shelf The location will also a require 1 lOVAC 
surge protected power supply for both the router and CSU/DSU. 

The next task of the walk-through inspection is discussion of the LAN design 
guidelines contained in Chapter V. The goal is not to design a LAN for the end user, but to 
enable the end user to consider LAN design options and to make an educated business 
decision at a later date. An equipment recommendation list is critical at this point to assist 
end users in understanding the financial impact of design options. The most frequently 
asked question during a walk-through is "how much does it cost." Of greater importance is 
communicating the need to invest up-firont in an inJfrastructure which will meet today's 
needs while remaining scalable in the future. 

A walk-through situation to avoid is one where a LAN already exists, and the 
maintainer of that LAN is not present at the brief In the K-12 educational sector it is not 
unusual for technology to be viewed as a display tool for casual use, rather than as an 
information resource which must be managed. In several walk-throughs end users expected 
the configuration team to have perfect knowledge of their network from the examination of 
a single terminal. Insist on the presence of the network administrator or consultant who 
maintains the system. 

The final task of the walk-through is to ensure that the end users understand the 
installation schedule and what roles PacBell, the configuration team and end user play. It 
must be clearly understood that PacBell will not install past the MPOE without prior 
agreement, and that PacBell's responsibility ends at the NIU (or at the RJ-48 if installed by 
PacBell). The end user is responsible for procurement of all equipment after the NIU, 
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especially the installation of all LAN hardware and wiring (if required). The configuration 
team's role is to assist in the configuration of WAN devices and software applications. 

C. WAN EQUIPMENT INSTALLATION AND CONFIGURATION 

The amount of information presented at the walk-through is substantial. On average 
the discussions lasted between two and three hours. Many requests for further information 
and clarification were received by the COEs and the configuration teams. In February a 
Frame Relay service "roll-out" schedule (included in the CIR matrix, Appendix J) was 
created by PacBell and the COEs. The roll-out was based upon the results of the walk¬ 
throughs completed and end-user requests. It is interesting that certain sites were already 
emerging as leaders in technology implementation. Without exception these sites had one 
or more champions who were willing to invest personal time integrating the technology 
successfully into their school [Gwinn, 94]. 

Figure 7.1 is a configuration team installation checklist. The checklist shows a 
logical progression through the configuration process. Many of the tasks can be performed 
simultaneously with multiple installers. The key learning points for the end user are the 
troubleshooting methods and corrective actions in the case of a suspected WAN error, and 
the functionality of the software applications installed on the computers. Training issues 
will be discussed in greater detail later in this chapter. 

During the configuration of the Cisco routers is was discovered that Cisco operating 
system version 10.2 or greater was required in order to implement the sub-interfaces for 
multiple point-to-point PVCs. Some of the routers were shipped with version 10.0 and had 
to be updated. The procedure for updating is contained in the Cisco support documentation 
chapter titled "UpgradingRun-From-Flash Software Images in the Cisco 2500" 

[Cisco, 95]. 
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• Configure TSU/DSU and router (Appendix G, H). Verify proper operation 
prior to installation. 

• Verify PacBell and LAN installation complete prior to installation. 

• Install router, TSU/DSU, and RJ-48 (if necessary - Appendix F). Verify 
adequate ventilation and power supply are available. 

• Verify connectivity from the router through the fi’ame relay cloud to another 
router. 

• Install proper transceiver (lOBASE-T or 10BASE2) and connect LAN to 
router. 

• Instruct end users in the meaning of the router, transceiver, and CSU/DSU 
indication lights. Discuss corrective actions and points of contact. 

• Verify all router and TSU/DSU documentation is presented to the end user. 

• Instruct end users in Class C IP address management. Assist them in starting 
a log of address assignments. 

• Install TCP packet drivers at each LAN terminal (Appendix O, P). 

• Install applications on each terminal. Explain Etidora mail program setup. 
Explain the cautions associated with CU-SeeMe use in Monterey BayNet. 

• Test and demonstrate applications. 

Figure 7.1 Configuration Team Installation Checklist. 

With the TSU (or DSU for 56 Kbps sites) and router configured and energized but 
not connected, the TSU will show green "PWR", "TD" and "RD" LEDs as well as a red 
"ALM" indication showing that Frame Relay service has been interrupted. Connecting the 
TSU "Network" port to the RJ-48 with the provided silver satin cable should clear the 
alarm indication. If this is not the case then there is a problem in the TSU, a wiring problem 
exists, or the Frame Relay signal has been lost. Troubleshoot in that order. Verify the TSU 
operation with a self-test. Verify the silver satin cable connectivity end-to-end on each pin. 
Verify RJ-48 wiring as per Appendix F. Finally contact the PacBell Network Operations 
Center at 1-800-870-9007. Have the circuit identification (written on the PacBell NIU) and 
a call-back telephone number ready. 

The router is connected to the TSU with the V.35 cable described in Chapter VI. 
This final connection should illuminate the remaining two LEDs "RTS" and "CTS". If this 
is not the case then there is a problem with either the router configuration or the V.35 cable. 
Troubleshoot them in that order. With all five of the green LEDs illuminated, no alarms. 
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the router can be used to verify WAN connectivity with a "ping" check to the COE 
(205.155.8.1 and 205.155.43.1 in Santa Cruz and Monterey respectively). 

At this point the WAN connection is completed. Ensure all documentation is 
consolidated and presented to the site's network administrator. Finally verify the LAN 
connection to the transceiver on router's Ethernet port. The remainder of the configuration 
will be conducted at each individual computer which desires access to the WAN. 

D. LAN CONFIGURATION AND APPLICATION INSTALLATION 

Each site has a class C address space assigned. It is the responsibility of the site 
network administrator to manage this block of addresses. Monterey BayNet convention 
assigns 205.155.Y. 1 to the router, 205.155.Y.2 is reserved for the site's (future) Web 
server. The remainder of the addresses (205.155. Y.3 through 205.155. Y.254) will be 
assigned to devices sequentially by the network administrator. Maintain an accurate log of 
address assignments. Label each device with the address to avoid confusion. 

MacTCP and Trumpet Winsock are the respective software packet drivers for 
Macintosh and Windows platforms. Each device that will have WAN access will need a 
packet driver installed and manually configured with the device's assigned IP address. 
Appendices O and P describe the packet driver installation and configuration procedure for 
the respective platforms. 

1. Configuration of Computers in the LAN 

The application software is installed on each computer in a folder (directory) titled 
Internet. Most of the applications are compressed and require expansion. On Macintosh 
platforms install the self-extracting program Stuffit-Expander from ihe Macintosh disk 1 of 
5 first. All other Macintosh applications can be installed by dropping them on top of the 
expander icon. The Windows extraction program is WinZip. WinZip is a self-extracting 
executable file. Copy WinZip to a temporary file in the file manager before executing, then 
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follow the installation prompts as they appear. The remainder of the Windows applications 
can be expanded by double-clicking on the files with .zip extensions. Some Windows 
applications may require the execution of setup files or modification of the path in the 
autoexec.bat file. Refer to the application's supporting documentation for specific 
installation instructions. 

2. Configuration of a Diskless LAN 

The software suite selected for Monterey BayNet was designed to be as inexpensive 
as practical while maintaining functionality. As a result the software is not networkable, i.e. 
it is for single users not multiple shared users. This implies that the application software 
must reside on each individual platform in order to give that platform the complete 
fimctionality of the associated application. If the software is called fi'om a file server then 
only one user will be able to access the application at a given time. 

El Sausel Middle School in Salinas California operates a (mostly) diskless LAN. 
Each computer is equipped with a boot ROM or boots from a floppy disk [Alvarez, 95]. 
Users login to the Novell file server to load Windows and the Internet applications. 
Configuration of terminals in a diskless LAN is nontrivial and beyond the scope of the 
configuration team's experience. El Sausel employed the services of a Novell CNE to 
configure their LAN. Unfortunately, because the software suite is not networkable, only 
one user can access each Internet application at a given time. This is not a side effect of a 
poorly designed network. Application servers are desirable in LANs. This is a function of 
the low-cost shareware software suite. Networkable software with the same functionality 
or better is available for a substantial fee. Other newer computers on the same LAN do 
have hard drives and are enjoying full Internet functionality. 
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3. Configuring Eudora Mail Program in a Multi-User Environment 


Eudora is the only user-specific software application in the shareware suite. It is 
necessary to set Eudora so that the personal configuration settings of each user are drawn 
from a personal disk. This prevents mail from being sent out under a false user name. In 
Windows this is accomplished by the configuration outlined in Figure 12. The Macintosh 
configuration of Eudora for multi-users is outlined in Figure 7.3. 


• Create a new directory called c;\eudora and copy weudora.exe into it. 

• Create a directory called c;\eudora\temp 

• Add the following environment variable to your autoexec.bat file: 

Set tiip=c : \eudora\ temp 

• Add Eudora as a new program item to a the Internet Program Group. 
•Modify the Eudora program Item as follows; 

Description: weudora 

Command Line: c: \eudoraXweudora. exe a: \ 

Working Directory: a: \ 


Figure 7.2 MuWi-wsqx Eudora Configuration Under Windows [Beckley, 94]. 


• Install Eudora on the Macintosh hard drive with no configuration parameters. 

• Store each user's Eudora Settings File on a floppy disk. 

Figure 7.3 Multi-user Configuration on a.Macintosh [Lapp, 95]. 

In both cases a unique diskette for each user will be required. To operate in the 
Windows environment the user will insert the disk into drive "A;" and then double click on 
the Eudora icon in the Internet group. In iht Macintosh case the user will click on the 
Eudora icon within his disk. In both cases this will start Eudora with the individual's unique 
configuration settings. 
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4. Responsible use of CU-SeeMe in Monterey BayNet 

CU-SeeMe is an interesting and powerful point-to-point videoconferencing 
application [Cogger, 95], Site administrators need to be advised that irresponsible CU- 
SeeMe usage can cause adverse effects in LAN and WAN response. CU-SeeMe requires 
large bandwidth and creates a continuous stream of data through the Frame Relay cloud. 
Recall that Frame Relay technology is based upon the transmission of variable length 
Frames over virtual circuits. Imposing a continuous stream of data over the Frame Relay 
circuitry effectively removes that amount of bandwidth from being shared with other clients. 

Read the accompanying documentation provided with CU-SeeMe before using the 
application. In particular read and comply with the recommendations on bandwidth 
adjustment. Do not transmit at greater then 80Kbps on the WAN. The best method of 
controlling CU-SeeMe access is to limit CU-SeeMe installation to supervised machines. 

56 Kbps Monterey BayNet sites should limit CU-SeeMe access to a single platform. The 
bottom line; CU-SeeMe can clobber the network so use it sparingly and carefully. 

E. SUPPORT 

Monterey BayNet is a fully operational network providing services today which are 
being used in participating schools throughout the region. The initial success has been 
largely due to the collective efforts of the PLA net design team in planning, implementing 
and training. In order for the technology to be fully integrated into the classroom 
environment it must be a reliable and dependable product. Educators need to understand 
the basics of the technology, the use of the applications, and know that the product will be 
available when they require it. This implies that a supporting structure of educator training 
and WAN management must be in place. These issues are currently being examined by the 
LLA and Monterey BayNet. The remainder of this chapter will highlight the critical areas 
of concern for Monterey BayNet future sustainability and growth. 
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1 . 


Formal End User Training 


A model for training educators in the use of the application software must be 
formalized and accessible. The I^LA white paper recommended the implementation of a 
"train the trainer" approach [Brutzman, 94], with Tier I and II sites being responsible for the 
training of Tier II and III sites. This method has achieved superior results in conveying 
specific material to limited groups on an ad hoc basis. As a final solution the "train the 
trainer" method does not scale to the scope of the target audience now attempting to access 
Monterey BayNet. Clearly ad hoc training is valued and appreciated, but a formal 
systematic approach which is designed within the bounds of the current education system is 
required in order to reach all educators. The I^LA and Monterey BayNet can assist in the 
development of the content for user training, but formalization must come from the County 
OflBces of Education. This issue closely parallels one responsibility of a Network 
Information Center (NIC) yet deserves immediate attention in the absence of an official 
NIC. 


2. Network Information Center (NIC) Justification 

A Network Information Center (NIC) is the group or organization which is 
primarily responsible for user services. This is not to be confused with connectivity. The 
NIC is not responsible for building or maintaining network connectivity. User services can 
generally be grouped into "help-desk" functions such as establishing new user accounts, 
answering questions about application software, training users, developing policy and 
directing users toward available resources. 

By default the county offices of education are performing the NIC function within 
Monterey BayNet because they are the only organization which can currently establish and 
maintain user accounts. The Lloyd Cyberstation used in Monterey BayNet provides a GUI 
which allows non-technical personnel to maintain accounts with relative ease. The larger 
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issue is the manning of the NIC with personnel who able to assist users with their questions 
and have the authority to develop and cany out training events. 

3. Troubleshooting Methodology 

The site network administrators require training in network administration 
particularly in troubleshooting methodology. Non-technical site administrators with 
questions are currently at the mercy of volunteer schedules and a single WAN administrator 
in each county office of education. A clear path for troubleshooting, system responsibility, 
and points-of-contact need to exist and be understood by local network administrators. 

The majority of network errors encountered throughout the implementation phase 
have been unrelated to WAN connectivity. Training local network administrators so that 
they can recognize that WAN connectivity exists (or doesn't) would greatly reduce the 
burden on the WAN administrators. The final goal should be local administrators who feel 
comfortable that they can isolate a problem to either a local node, WAN access, or access 
beyond Monterey BayNet. In each case the local network administrator needs to 
understand who the responsible agent is for correcting the error and how to contact them. 
This issue closely parallels one responsibility of a Network Operations Center (NOC) yet 
deserves specific attention in the absence of an official NOC. 

4. Network Operation Center (NOC) Justification 

A Network Operations Center (NOC) is the group or organization responsible for 
the day-to-day maintenance of the WAN. This is accomplished through the monitoring of 
online statistics including traffic patterns, congestion reports and data fi'om SNMP clients. 
Many software packages exist which aid in the recognition of network problem areas. 
Unfortunately resolution of these problems must be accomplished manually and often 
requires significant technical expertise. Nevertheless many large and small organizations do 
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not have a formalized NOC. All organizations have a person or persons which perform that 
role, with or without the aid of automated monitoring devices. 

The Monterey BayNet NOC function is currently being carried out by the collective 
members of the I^LA network design team in cooperation with the county office of 
education WAN administrators. This approach is not sustainable. The responsibility for 
communication with the Internet provider. Pacific Bell, contractors, and numerous 
manufactures has too many legal ramifications to remain in the domain of volunteers, 
regardless of how qualified they may be. By default the role of the NOC falls to the county 
offices of education. This function can also be easily outsourced to any competent service 
provider with the required facilities and staff. The PLA is working with Monterey BayNet 
to resolve NOC transition requirements. 

F. IMPLEMENTATION SUMMARY 

The Monterey BayNet WAN is being successfully implemented in a three phase 
process which includes initial site inspection, informal follow-up, and installation. To date 
25 of the 43 CalREN sites are online and installation efforts continue. Monterey BayNet is 
providing all of the services specified in the end user requirements. The technical problems 
of implementation are rapidly giving way to human ones. The need for consistent and 
available training on the use of the software applications provided, as well as the need for a 
readily available information and assistance center are the driving factors of the next phase 
of the implementation. The implications of delaying the implementation of a full scale NIC 
and NOC could be cause for concern. 

Areas for continuing research include NIC and NOC design and deployment, policy 
development in the K-12 Internet environment and models of technology integration in the 
classroom. In the area of human resource management further research could study the 
reaction of technology intervention in the Monterey BayNet education system. New lines 
of communication are being formed by technology in education and the long term result 
may be nothing short of full scale restructuring of the education model. 
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Vm. APPLICABILITY TO DEPARTMENT OF THE NAVY (DoN) SHORE 

COMMANDS 


A. INTRODUCTION 

The Monterey BayNet project has numerous learning points that transition directly 
from the K-12 environment into wide area networking efforts within Department of the 
Navy shore commands. The Monterey BayNet effort focused on a population of end 
users with minimal networking skill levels sparsely distributed over a large geographic 
region. Using commercial off the shelf (COTS) products and requiring no new studies, 
this group of volunteers implemented a WAN capable of high-speed communication of 
voice, data and images. 

B. REQUIREMENTS DEFINITION 

Monterey BayNet spent considerable time attempting to define the baseline system 
requirements for end users. This first step in the systems development life cycle is critical 
in that it forms the foundation for network design and applications development 
[Whitten, 89]. The process included a thorough review of available K-12 networking 
documentation, applicable grant documentation and most importantly end user interview 
and observation. The requirements which were defined in this process played a leading 
role in the subsequent development of the software applications, minimum recommended 
personal computer hardware, telecommunications service selection, and implementation 
methodology. 

Understandably defining end user requirements is much like tiying to paint a 
moving train, but the time spent understanding the scope of the problem and the expected 
outcomes clearly enabled the net design team to focus its efforts on a shared vision. 
Further refinement of the end user requirements will be easier now that there are tools in 
place to measure and evaluate. 
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c. 


DESIGNING FOR GROWTH 


The network design team's focus on scalability in every aspect of design is critical 
to the long term success of the network. In LAN design recommendations were focused 
toward the implementation of lOBASE-T designs to allow migration paths for further 
network expansion. The physical infrastructure recommended the installation of upgraded 
UTP, where new wire was required, to allow future expansion to 100BASE-T. In WAN 
design the recommended entry level was 128 Kbps to allow future increases in frame rate 
without the need to invest in additional hardware. The one fact that can be relied upon is 
that networks will grow in size and applications will require increasingly higher data 
transfer rates. Monterey BayNet and the Monterey BayNet sites have the ability to 
expand in both directions. 

D. STANDARDIZATION 

Early standardization of hardware increased the manageability of the network. 

The configuration team was required to learn only a few systems in order to effectively 
connect sites. Standardization also assured interoperability within the WAN. The 
economies of scale generated by group purchase techniques generated cost savings as well 
as manufacturer attention and support for the project. 

E. COST REDUCTION 

The Monterey BayNet project achieved dramatic results in an extremely cost 
conscious environment. Similar methods applied in DoN networking projects may yield 
the same result. No new studies were required or requested in the design and 
implementation of the network. All solutions were COTS products and all technology 
used was proven in industry prior to the network design team's consideration. Savings at 
the local level were promoted through the effective evaluation of existing infrastructure. 
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Many schools were able to reuse excess capacity wiring for LAN installation. The use of 
on-site personnel to run new cable installations greatly reduced cost to schools. 

F. MAEVTAINABILrrY 

Simple Network Management Protocol (SNMP) clients and WAN management 
applications are valuable tools to assist personnel in the management of a WAN. These 
tools are not a substitute for knowledgeable technicians who can address problems as they 
are identified. The question to be considered in planning NIC and NOC functions is not a 
technical question as much as it is a human one. NIC and NOC staffing and a plan on how 
to address technical and human issues are much more valuable than a software suite which 
allows an operator to pinpoint a problem without the means to correct it. 

G. SUMMARY 

Monterey BayNet serves as a practical reminder that networking solutions must be 
oriented to the end user and not the technology. Wide-area network connectivity can be 
achieved in a manner which optimizes economy and design. Infrastructure design and 
installation can be accomplished with nontechnical personnel at great savings. The 
management and maintenance of a network is simplified though standardization. Finally 
maintenance is a personnel problem, not a technical problem. Technical issues have 
technical solutions, whereas people issues require people solutions. 
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IX. CONCLUSIONS 


Monterey BayNet works! 

Students and educators began collaborating via the Monterey BayNet on March 
24th 1995. The network is obviously still in its infancy and there are a number of 
personnel issues to resolve, but the end user requirements which were defined in Chapter 
rv are being met and exceeded. Monterey BayNet provides an information infrastructure 
that enables such a fundamental shift in the educational paradigm that it may take years to 
fully resolve the issues of integration within the educational system and the impact on 
teaching and learning. The reactions of the students and parents of the Monterey 
Academy of Oceanographic Sciences (MAOS) clearly indicate that student and parent 
interest is enormous. Students and parents alike were captivated by the concept of being 
able to share their research with the world. The end product at MAOS was a dedicated 
student effort to create a home page which expressed their research project results as well 
as their enthusiasm. The URL for MAOS is http://205.155.54.2/maos/home.html 
[Pool, 95], 

The key to Monterey BayNet success has been the dedication of the individuals 
involved with the collaborative effort. A single expert does not exist. Interested 
educators, researchers and technicians have doggedly pursued a common vision to 
fiaiition. The fact that Monterey BayNet has arrived at this stage after little more than one 
year is nothing short of remarkable and speaks volumes about the strength of the 
collaborative effort in Monterey Bay. 

A second key contributor to success has been the continual focus on the end user. 
This author finds it remarkable that some sites have networked every room of their entire 
campus without outside assistance. The technology transfer discussed in Chapter V 
combined with the information presented in the appendices is literally all of the guidance 
used in most cases throughout Monterey BayNet. Student volunteers from the Naval 
Postgraduate School and Cabrillo College assisted in the technology transfer process by 
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conducting walk-thru inspections, usually learning more from answering the end user 
questions than the end user did. 

The final linchpin was the terrific assistance provide by Pacific Bell, Cisco, and 
Lloyd Internetworking. The final implementation of the WAN could not have been 
coordinated better or benefitted from stronger partners. The relationships fostered with 
these corporations have greatly assisted the members of the PLA net design team to 
understand the technical issues as they developed. 

Collaboration implies cooperation, a give and take relationship which is founded 
on trust and vision. While at times the speed of the consortia seemed appallingly slow, it 
is equally true that when a decision is finally reached it has been completely examined, 
often repeatedly. This is beneficial to the final product, provided that the central focus 
does not waver. Monterey BayNet's measure of success has continually remained the 
number of students and teachers online. This focus has been crucial in achieving success 
to date. 

Further research continues within the FLA net design team. The next phase of 
Monterey BayNet development must veer radically from the technical issues to address the 
people and policy issues. Training, user support, manning of a network information center 
(NIC), and providing a plan for technical support (NOC functions) are all issues which 
must be resolved for Monterey BayNet to be sustainable after the CalREN grant expires. 

A key ingredient again must be end user "buy in". This author feels strongly that the best 
mode of accelerating educator acceptance of technology is to grant them access to the 
same applications from home. Dial-in service limited to educators can allow the educators 
the leisure of learning "what" and "how" from home, creating a "Tier IV" of access. 
Limiting that access to educators is an important policy question. Monterey BayNet may 
not want to place themselves in a position where they are competing with local Internet 
providers for the home dial-in market, namely parents. On the other hand, providing some 
additional access might support financial sustainability. 
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In summary the processes used to develop Monterey BayNet all focused on 
meeting the requirements of the end user today and in the future. Design efforts stressed 
upward bandwidth transition paths and well as LAN expansion paths. The WAN stressed 
equipment standardization to assure interoperability and management sanity. SNMP was 
recommended to allow future growth toward remote WAN monitoring to assist end users, 
Every facet reflects end user ease of use, manageability, and scalability. 


77 





APPENDIX A. MACINTOSH SOFTWARE DOWNLOAD SITES 


The following is a list of the Monterey BayNet recommended software for 
Macintosh platforms. This list reflects the latest versions of software as of this writing. 
Pointers to download sites listed can be found at http://monterey.kl2.ca.us/ 
macsoft.html. This list is maintained by the Monterey BayNet system administrator and 
will reflect updates as they are implemented within Monterey BayNet. 

Not all of the software is free. Review the copyright of every piece of software 
that is being installed. It is the responsibility of the system administrator to ensure 
compliance with all license and copjoight requirements. 

File extensions (.sit, .sea, .bin and .hqx) are used to indicate what format the file 
has been stored in. The hqx (BinHexed) extension is normal and will be transparent to 
Macintosh users. The same holds true for files with the .bin (Binary) extension. All files 
with the extension .sit (StufF-It) will have to be extracted with the Stuffit Expander or 
similar application. The extension .sea (Self Extracting Archive) indicates that the file will 
automatically expand itself Each application has a compressed file size listed. Total 
system disk space required for a complete software installation is approximately 45 
megabytes (MB). 

MacTCP PROPRIETARY 

MacTCP is the software which enables TCP/IP connectivity. MacTCP software comes 
bundled with the system 7.5 operating system. All older operating systems require a 
licensed copy o^MacTCP. The easiest way to obtain MacTCP is through the purchase of 
The Internet Starter Kit for the Macintosh (currently $29.95) at many bookstores 
[Engst, 94], 

Netsccq)e - Version 1. IN - Windows version available. FREE EDUCATIONAL USE 
A graphical WWW browser. 

ftp://ftp. mcom. com./netscape/mac/netsccq)e_l. IN. hqx 
1625 KB 

Eudora - Version 2.1.1- Windows version available. FREEWARE 

Send and receive electronic mail. 

ftp://ftp. qualcomm. com/quest/mac/eudora/1.5/eudoral52fat. hqx 
649 KB 

NewsWatcher - Version 20b27 FREEWARE 

A news reader. Note that news groups must be made available from the Internet provider. 
ftp://ftp.acns.nwu.edu/pub/newswatcher/newswatcher-20b27.sea.hqx 
625 KB 
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FREEWARE 


Fetch - Version 2.1.2 

A File Transfer Protocol (FTP) application for th& Macintosh. 
file://ftp.dartmouth. edu/pub/mac/Fetch_2.1.2.sit.hqx 
363 KB 

Anarchic - Version 1.4 FREEWARE 

An FTP and Archie client. Archie is a method of searching FTP sites for information. 
ftp://boombox, micro, umn. edu/pub/gopher/Macintosh-TurboGopher/helper-applications/ 
Anarchic-140. sit. hqx 
490 KB 

Telnet - Version 2.6 - Windows version available. FREEWARE 

Enable virtual terminal access to remote hosts. 
file://ftp. ncsa. uiuc. edu/Mac/T?lnet/Telnet2.6. sit. hqx 
167 KB 

TurboGopher - Version 2.0b7 - Windows version available. FREEWARE 

A Gopher client for the Macintosh. Enables the download of files from Gopher servers. 
ftp://boombox.micro. umn. edu/pub/gopher/Macintosh-TurboGopher/TurboGopher2.0.sea. hqx 
316KB 

GifConverter SHAREWARE $40 

Graphic image viewer and processor. Reads and writes the following graphics file formats; 
GIF, MacPaint, PICT, RIFF, RLE, Thunderscan, Startup Screen, TIFF and JPEG. 
file://ftp. ncsa. uiuc. edu/Mac/Mosaic/Helpers/gif-converter-237. hqx 
474 KB 

JPEGView - Version 3.3.1 POSTCARDWARE 

Graphic image viewer and processor. Reads and writes the following graphics file formats: 
JPEG, JFIF, GIF, PICT, Baseline and LZW-compressed TIFF, Windows BMP, Startup 
Screen, and MacPaint. 

file://ftp. ncsa. uiuc. edu/Mac/Mosaic/Helpers/jpeg-view-331. hqx 
769 KB 

SoundMachine FREEWARE 

Audio file player for SND/AU and AIFF/AIFC formats. 

file://ftp. ncsa. uiuc. edu/Mac/Mosaic/Helpers/sound-machine-21. hqx 

74 KB 

Sparkle - Version 231 FREEWARE 

MPEG and QuickTime movie viewer. 
file://ftp.ncsa. uiuc. edu/Mac/Mosaic/Helpers/sparkle-231, hqx 
1109KB 
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FREEWARE 


SimplePlayer 
A quicktime movie viewer 

file://ftp.ncsa. uiuc. edu/Mac/Mosaic/Helpers/fast-player-110. hqx 
13 KB 

Stuffit Expander - Version 3.5.2 FREEWARE 

Create compressed archives and decompress common Macintosh archived formats. 
file://ftp.ncsa.uiuc.edu/Mac/Mosaic/Helpers/stufftt-expander-352.hqx 
186 KB 

DropStuff- Version 3.5.2 SHAREWARE $30 

Enhanced version of Stuffit Exparuier. Create compressed archives and decompress 
archived formats including ZIP (.zip) and ARC (.arc) archives; AppleLink ( pkg) 
packages; gzip (.gz), Unix Compress (.Z), UUencoded (.uu), and Stuffit files ( sit). 
file://ftp.ncsa. uiuc. edu/Mac/Mosaic/Helpers/drop-stuff-with-ee-352. hqx 
521KB 

NCSA Collage - Version 1.2- Windows version available. FREEWARE 

A shared whiteboard application. 

file://ftp. ncsa. uiuc. edu/Mac/Collage/Collage 1.2/Collage 1.2. sit. hqx 
661 KB 

BBEditLite - Version 3.0 FREEWARE 

A high performance text editor. 

file://ftp. ncsa. uiuc. edu/Mac/Mosaic/Helpers/bbedit-lite-30. hqx 
392 KB 

B^^(ir?-html-extension FREEWARE 

Add-on extensions to BBEdit Lite which enable use as an HTML editor. 
file://ftp. ncsa. uiuc. edu/Mac/Mosaic/Helpers/bbedit-html-b8. hqx 
78 KB 

CU-SeeMe - Windows version available. FREEWARE 

Point-to-point videoconferencing. 

fip://CU-SeeMe.comell.edu/pub/CU-SeeMe/Mac.CU-SeeMe0.80b2/CU-SeeMe.68k0.80b 

2.bin 

224 KB 

Disinfectant - Version 3.5 FREEWARE 

A program designed to detect and remove all known Macintosh viruses. 
fip://ftp.acns.nwu.edu/pub/disinfectant/disinfectant36.sea.hqx 
232 KB 


81 



MacTCP Watcher - Version 1.12 FREEWARE 

Application which displays IP and DNS information. Network testing. 
ftp://redback.cs.iiwa.edu.au/Others/PeterLewis/MacTCPWatcher-112.sit 
79 KB 

BLUE SKIES - Version 1.1 FREEWARE 

Interactive weather information. 

gopher://groundhog, sprl. umich. edu/1 l/Software/Blue-Skies_yl. 1. sea. hqx 
251 KB 

MacWeather - Version 2.0.4 FREEWARE 

Current weather information and forecasts. 

ftp ://cirrus. sprl.umich.edu/pub/Other_Software/Weather_Software/macweather2.04.hqx 
116KB 

Adobe Acrobat - Windows version available. 

A Portable Document Format (.PDF) file viewer. 
ftp-.//boombox.micro.umn. edu/pub/gopher/Macintosh 
AcrobatReader/AcrobatReader2.0. l.hqx 
2919 KB 

GhostScript - Windows version available. FREEWARE 

A PostScript (.PS) file viewer. 
ftp://ftp. cs.wisc. edu/pub/ghost/aladdin/mac/ 

714 Kbps macgs-vl.O-files.sit - G/jost&r/pt files and documentation 
438 Kbps macgs-vl.0-68k.sit - the application compiled for 68020 or better 

2782 Kbps macgs-v 1.0-fonts.sit - the standard 3.0 fonts 

17 Kbps manual.txt - the manual as unformatted text 

1 Kbps readme.txt -instructions! 

InterSLIP FREEWARE 

Serial Line Internet Protocol (SLIP) makes TCP/IP communication possible via modem, 
http://www. Utah. edu/HTMLhocs/InterSLlP/InterSLIP. html 
267 KB 

MacPPP FREEWARE 

Point-to-Point Protocol (PPP) makes TCP/IP possible communication via modem. 
MacPPP is bundled with MacTCP when you purchase The Internet Starter Kit 
[Engst, 94]. 

ftp://ftp.merit.edu/intemet. tools/ppp/mac/macppp2.0. l.hqx 
75 KB 


FREEWARE 

-TurboGopher/helper-applications/ 
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APPENDIX B. WINDOWS SOFTWARE DOWNLOAD SITES 


The following is a list of the Monterey BayNet recommended software for 
Windows platforms. This list reflects the latest versions of software as of this writing. 
Pointers to download sites listed can be found at http://monterey.kl2.ca.us/ 
ibmsoft.html. This list is maintained by the Monterey BayNet system administrator and 
will reflect updates as they are implemented within Monterey BayNet. 

Not all of the software is free. Review the copyright of every piece of software 
that is being installed. It is the responsibility of the system administrator to ensure 
compliance with all license and copyright requirements. 

File extensions (.zip) are used to indicate what format the file has been stored in. 
All files with the .zip (PKWare compression) extension will have to be extracted with the 
WinZip application. Each application has a compressed file size listed. Total system disk 
space required for a complete software installation is approximately 45 Megabytes (MB). 


Trumpet Winsock Version 2.0 
The software which enables TCP/IP connectivity. 
ftp. cica. indiana. edu/ftp/pub/pc/wm3/winsock/twsk20b. zip 
179 KB 


SHAREWARE $25 


Netscape - Version I.IN -Macintosh version available. 
A graphical WWW browser. 
ftp://ftp. mcom. com/netscape/windows/ns 16-100. exe 
706 KB 


FREE EDUCATIONAL USE 


Eudora - Version 1.4.3 - Macintosh version available. 

Send and receive electronic mail. 

ftp. cica. indiana. edu/ftp/pmb/pc/win2/winsock/eudorl43. exe 
303 KB 


POSTCARDWARE 


^/nFVNNTP newsreader FREEWARE 

A news reader. Note that news groups must be made available by the Internet provider. 
ftp.cica.indiana.edu/ftp/pub/pc/win3/winsock/winvn926.zip 
176 KB 


FTP - Version 94.03.25 FREEWARE 

A File Transfer Protocol (FTP) application that enables the download (and upload) of files 
from FTP servers. 

ftp://ftp. csusm. edu/cwis/winworld/winsock/wsjtp. zip 
69 KB 
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Archie FREEWARE 

An FTP and Archie client. Archie is a method of searching FTP sites for information. 
ftp://ftp.csusm.edu/cwis/winworld/winsock/wsarchie.zip 
159 KB 

PING, WINCHAT, View, Winarch, Trumptel(Telnet) FREEWARE 

A group of standard applications which allow you to retrieve IP and DNS information, 
conduct network tests, perform online "chat" sessions with other users, and enable virtual 
terminal access to remote hosts. 
ftp://ftp. utas. edu. au/pc/trumpet/winsock/winapps2. zip 
124 KB 

WinGopher - Macintosh version available. FREEWARE 

A Gopher client for Windows. Enables the download of files fi'om Gopher servers. 
bcinfo. be. edu/pub/bcgopher/BCC08BA 3.EXE 
170469bytes 

LView 31 FREEWARE 

Graphic image viewer and processor. 

file://gatekeeper.dec. com/.f/micro/msdos/win3/desktop/lview31.zip 
234 KB 

Wham - Version 1.31 $20-$30 DONATION ENCOURAGED - SHAREWARE 

Audio file viewer and processor. 

ftp://gatekeeper.dec.com/pub/micro/msdos/win3/sounds/whaml31.zip 
138 KB 

Quicktime - Version 1.1- Macintosh version available. SHAREWARE 

A quicklime movie viewer. 

bcinfo. be. edu/pub/bcgopher/qtwl 1. exe 

622 KB 

MPEGXING FREEWARE 

An MPEG movie viewer. 

ftp-.//bcinfo. be. edu/pub/bcgopher/MPEGEXING.EXE 
478 KB 

WinZip 5.5a w/built-in ZIP+UNZIP; Drag & Drop SHAREWARE $29 

Create compressed archives and decompress common Windows archived formats. 
http://www. acs. Oakland edu/oak/Sim Tel/win3/winzip55. exe 
284 KB 
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FREEWARE 


NCSA Collage for Winsock - Macintosh version available. 

A shared whiteboard application. 
ftp. cica. indiana. edu/pub/pc/win5/winsock/col_12bl.zip 
204 KB 

Hotmetal - HTML Editor FREE FOR EDUCATIONAL USE 

A Hyper Text Markup Language (HTML) editor. 

gatekeeper.dec.com/pub/net/infosys/NCSA/Web/html/hotmetal/hotmetal.exe 
1361KB 

CU-SeeMe - Macintosh version available. FREEWARE 

Point-to-point videoconferencing. 

ftp://CU-SeeMe. Cornell. edu/pub/video/PC. CU-SeeMe 

224 KB 

F-Prar Anti-virus SHAREWARE $20 

Virus detection and removal software. 
http://id.proper, com/pc/files/fprot. zip 
514 KB 

Adobe Acrobat Reader - Macintosh version available. SHAREWARE 

A Portable Document Format ( pdf) file viewer. 
ftp://ftp.cuiobe.com/pub/adobe/Applications/Acrobat/Windows 
1438 KB 

GhostScript for Windows - Macintosh version available. FREEWARE 

A PostScript (.ps) file viewer. 

http://www. cs. wise. edu/~ghost/ghostscript/obtaina. html 

504 KB gs333ini.zip - Configuration, initialization, and example files. 

440 KB gs333win.zip - MS-Windows 16 bit version. 

1344 KB gs333fiil .zip - GhostScript standard fonts. 

576 KB gsviewl3.zip - G.S'v/^ previewer. 
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APPENDIX C EIA/TIA-568B WIRING SCHEME IN A lOBASE-T PLUG 


This is a drawing of the lOBASE-T plug specified in the IEEE 802.3 standard 
[IEEE, 90b]. The connector is commonly (and improperly) called an RJ-45. The proper 
name is an eight position modular plug. It connects 4 pairs of wires as shown below. The 
wiring scheme is simple in concept, yet somewhat time consuming in practice. Be sure to 
verify all wiring with a lOBASE-T tester box immediately after connection. More 
information on the design of lOBASE-T local area networks can be found in Chapter V. 


This is an 6-Pc3sifon Modular Plug, 
often incorrectly referred te 
as an RJ-45. 


EIA/TIA-568B 
Wiring Scheme 


10BASE-T use 

6 Unused 

7 Unused 

6 DalaRecreire-> 
5 Unused 
4 Unused 
^ DabReDeire + 
2 DabTransmft- 
1 Dab Transmi 


345 


67 8 


10BASE-T wiring specifies an S-positlon jack but useson^ Orangek 

pairs 2 and 5 of the EIA/TIA-566B scheme. Pair 1 is not used 
because that position is used in conventbna! telephone service and 
carries voltage when the telephone rings. This voltage would damage your NIC. 
The forthcoming 100BASE-T standard will use all four pairs. 


Pair 3 Green 


Figure C.l EIA/TIA-568B wiring scheme. 
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APPENDIX D. EXAMPLE LAN DESIGNS 


Local area network (LAN) design was discussed in detail in Chapter V. The 
following designs are typical of those that have been built within Monterey BayNet 
schools. The first design (Figure D.l) is from the Main Street School in Soledad 
California. Faculty members pulled new category 5 wire from a central lOBASE-T hub 
located at the MPOE to two computer labs located on the campus. The central hub has 
excess capacity (unused jacks), as do the hubs installed in the two classrooms. This will 
make future expansion to other areas on the campus easy and affordable. The LAN is 
connected to the WAN with a Cisco 2511 router and Adtran TSU. The 2511 will also act 
as a terminal server, allowing dial-in access to the WAN via a bank of 8 modems. Main 
Street School has a 128Kbps Frame Relay connection to Monterey BayNet. All LAN 
internal connections use Ethernet. This is the recommended model for school LAN design 
i.e. A lOBASE-T LAN with a central hub at the MPOE servicing hubs in each buildin 





Figure D.l Main Street School lOBASE-T LAN 










Seaside High School (Figure D.2) has a 10BASE2 backbone serving 11 nodes. 
Two of the nodes are hubs which allow lOBASE-T connections to 12 Quadra 610s. 
Three other Quadras are attached directly to the backbone in the reading room. The 
circulation desk, office and file server are IBM clones with 486 processors. Novell 
Netware 4.1 is the network operating system. The LAN is connected to the WAN with a 
Cisco 2511 router and Adtran TSU. The 2511 will also act as a terminal server, allowing 
dial-in access to the LAN via a bank of 8 modems. Seaside High has a 128Kbps Frame 
Relay connection to Monterey BayNet. 



Figure D.2 Seaside High School Library lOBASE-2 LAN 


The Monterey Bay Technology Education Center (MBTEC) and Fitch Middle 
School share a common campus. A single 384 Kbps Frame Relay line services both clients 
via a Cisco 2514 dual port router (Figure D.3). IVffiTEC has a 10BASE2 backbone 
serving a single node. The node is a 24 port hub which is directly connected to a second 
24 port hub. The two hubs service a lOBASE-T raceway spanning all four rooms of the 
MBTEC facility. Novell Netware 4.1 is the network operating system. The file server is 
physically located in room A-4. 

The Fitch Middle School LAN is a lOBASE-T network originating at the Cisco 
2514 router and servicing a 12 port hub in the library. The circulation desk, reference 
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area and file server are IBM clones with 486 processors. Novell Netware 4.1 is the 
network operating system. The student access area is a cluster of Macintosh platforms. 
All library devices are connected to the hub with Category 5 UTP wire. 

Note that a hub was not placed at the MPOE. When the administration building 
desires to connect to the LAN a hub will be required at the MPOE. The present design 
meets all current requirements and allows for easy expansion. 



Figure D.3 Monterey Bay Technology Education Center (MBTEC) and Fitch Middle 
School LAN's connected by a Cisco 2514 dual port router. 
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APPENDIX E. MONTEREY BAYNET EQUIPMENT RECOMMENDATIONS 


These are the original Monterey BayNet equipment recommendations. Chapters 
V, VI and VII have noted repeatedly the benefits of equipment standardization throughout 
LAN and WAN design. It is also be noted that technology evolves rapidly, delivering 
better and cheaper products to market. Always consult with the WAN system 
administrator and/or Internet provider prior to purchasing new equipment. The following 
recommendations were published in March 1995 [Herbst, 95a]. Prices, delivery terms, and 
warranty are subject to change, caveat emptor. 

Router: 

Cisco 2500 series: 

Cisco 2514 Dual LAN router (recommended) 

Cisco 2501 Single LAN router 
Cisco 2511 Single LAN router with terminal service 

CSU/DSU: 

Adtran. 

T1 CSU for 128Kbps thru 1.5Mbps Frame Relay service 
Model Adtran TSU 

ADN CSU for 56Kbps Frame Relay service (not scalable) 

Model Adtran 56/64 


Ethernet Card: Eagle/Artisoft ^^2000+ $74.83 

Smart Hubs (SNMP agent - recommended): 

Asante AH1012-12 w/SNMP 99-00028-01 

Asante Netstacker Base 24 99-00188-01 

Cabletron 10 T12 Port SEHI-22 

Cabletron 10 T 24 Port SEHI-24 

Allied Telesyn 10 T 24 port AT-3624TRS-15 

Non-InteUigent Hubs (not recommended): 


Cabletron 

10 T 12 Port 

SEH-22 

$575.00 

Cabletron 

10 T 24 Port 

SEH-24 

$812.00 

Asante 

10 T HUB 8 port 

99-00299-01 

$149.00 

Asante 

10 T HUB 12 port 

99-00280-01 

$299.00 

Asante 

10 T HUB 24 port 

99-00281-01 

$395.00 


$750.00 

$1199.00 

$1140.00 

$1430.00 

$673.00 


$902.00 

$225.00 
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Allied Telesyn 

10 T 12 port 

AT-3612TR-15 

$517.40 

Allied Telesyn 

10 T 12 port 

AT-3612TR-18 

$618.80 

Allied Telesyn 

10 T 14 port 

AT-3624TR-15 

$777.40 

Allied Telesyn 

10 T 14 port 

AT-3624TR-18 

$878.80 

Network management program for Windows (Not available for Mac) 


Castlerock SNMPc 3600 Release 3.3 

AT-10070 

$257.00 
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APPENDIX F. REGISTERED JACK NUMBER 48 (RJ-48) PINOUT AND 
WIRING BETWEEN NIU AND CSU 


The Figure F. 1 shows the physical wiring installed by PacBell at the minimum 
point of entry (MPOE) as described in Chapter VI. Recall that PacBell charges for the 
installation of the RJ-48. Monterey BayNet recommends that PacBell install the RJ-48 in 
those cases where the RJ-48 is not collocated with the PacBell Network Interface Unit 
(NIU). 

Wiring from the NIU to the RJ-48 consists of 2 pairs of 24 gauge wire. The pairs 
are terminated on the punchdown block of the RJ-48 as described in the RJ-48 pin 
connections table below [Adtran, 94]. Note that the RJ-48 pinout varies depending upon 
the type of channel switching unit at the site. 

The cable from the RJ-48 to the CSU is provided with the CSU. The cable is an 8 
position modular plug to 8 position modular plug wired straight-thru using the EIA/TIA- 
568B wiring scheme discussed in Appendix C. 


R1 LOOP 1 ^ 

T1 LOOP1 
R LOOP 2 0; 

T LOOP 2 ® 

T1 TO CPE 0.^ 
R1 TO CPE 
T FROM CPE 0 /I 
R FROM CPE 0 , 


IWPI IT NIU 


INPUT 

From 

PacBell 


isH 


Output 
To RJ-48 


RJ-« ^ 

The wiring of the 3 Position 

RJ-18 vanes. J tiiOduiarplugtoS 
See table below Position jack on CSU 


RJ-48 PIN CONNECTIONS 
*IN Adtran TSU use Adtran 56/64 use 

1 R1 RXDATA-ring RTXDATA-ring 

2 T1 RXDATA - tip T TXDATA - tip 


unused 


unused 


R TXDATA - ring unused 
T TXDATA - tip unused 


6 unused 

7 unused 

8 unused 


unused 

T1 RXDATA-tip 
R1 RXDATA - ring 


Figure F.l RJ-48 pinout and wiring between NIU and CSU. 
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APPENDIX G. CHANNEL SERVICE UNIT/DIGITAL SERVICE UNIT 
(CSU/DSU) CONFIGURATION 


Chapter VI described the role of the CSU/DSU in the WAN. Figure G. 1 is the 
Adtran T-1 Service Unit (TSU) configuration menu tree with settings for a 128Kbps site. 
The Adtran TSU performs the role of both CSU and DSU [Adtran, 94], The Channel 
Service Unit (CSU) function allows the TSU to be programmed to accept any number of 
channels up to a full T-1 service rate of 1.5 Mbps. Each channel is 64Kbps. 128 Kbps sites 
select two channels, sites with rates higher than 128Kbps adjust the number of channels 
accordingly. The Digital Service Unit (DSU) function programs the position of the data in 
the T-1 stream. 



FORMAT; 


ESF 



CODE; 


B8ZS 



NETWORK 

YELALRM; 


ENABLE 



XMIT PRM: 






CLOCK SOURCE: 

NETWORK 



BIT STUFFING; 

DISABLE 



SETLBO: 


0.0 







POSITION: MASTER 



CNTRL PORT 



MODEM INIT: DISABLE 

CONFIG 

UNIT 




DATA RATE: 9600 








ALARMS 



TRAPS: DISABLE 






OUTPUT: UIRbLi 






TEL NUM: IBUNK) 



RATE 56/64: 

64 





CHANNELS: 

CONTINUOUS 



DTE TX CLK: 

INTERNAL 



PORT 

START CHAN: 

01 




# OF CHAN: 

02 




DATA: 

NORMAL 



CTS: 

NORMAL 



DCD: 

NORMAL 



DSR: 

NORMAL 



Figure G.l Adtran TSU configuration menu tree with settings for a 128 Kbps site 
[Adtran, 94]. 
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Figure G.2 is the dip-switch configuration of the Adtran 56/64 DSU. Note that 
the CSU function is not required since the site is not receiving the multiple channels 
associated with fi'actional T-1 lines. 


* * * * t t * t 

SWl SW2 SW3 SW4 SW5 SW6 SW7 SW8 

Figure G.2 Adtran 56/64 DSU dip-switch configuration (56 Kbps sites). 
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APPENDIX H. CISCO 2514 ROUTER CONFIGURATION 


Chapter VI described the origin of the WAN and LAN configuration parameters 
used in the following configuration script. The script is included as an example of the 
router configuration process and to document a successful Cisco 2514 configuration 
script. The site being documented is the dual port LAN of Monterey High School and the 
Monterey Academy of Oceanographic Science (MAOS). In viewing the script note that a 
single physical WAN connection exists on serial port zero. Two PVC's are created linking 
the site to the Monterey County Office of Education (MCOE) and California State 
University Monterey Bay (CSUMB). The two links enable Internet access and Domain 
Name Service (DNS) respectively. 

NOTE: If this is the first time you enter the Cisco router configuration program 
you Avill automatically get the global setup menu. If you need to change global parameters 
later, type "setup" while in the enable mode. This file is a copy of the initial setup script of 
a Cisco 2514 running version 10.2 software. Italic script indicates computer generated 
summary information. Capitalized and boldface information indicate user input. [] 
indicates Cisco default settings. No boldface answer indicates that the default settings 
enclosed in the [] brackets were used. 

Would you like to enter the initial configuration dialog? 
[yes] 

First, would you like to see the current interface summary? 
[yes] 


Interface 

IP-Address 

OK? 

Method 

Status 

Protocol 

E theme to 

unassigned 

NO 

not 

set 

up 

down 

SerialO 

unassigned 

NO 

not 

set 

down 

down 

Serial1 

unassigned 

NO 

not 

set 

down 

down 


Configuring Global Parameters; 

Enter host name [router]: MHS 

Enter enable password: XXXXX 

Enter virtual terminal password: CISCO 
Configure SNMP Network Management? [yes]: NO 
Configure DECnet? [no]: 

Configure AppleTalk? [no]: 

Configure IPX? [no]: 

Configure Bridging? [no]: 

Configure IP? [yes]: 

Configure IGRP routing? [yes]: 

Your IGRP autonomous System Number is [1] : 11 
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Configuring interface parameters: 

Configuring interface EthernetO: 

Is this interface in use? [yes]: 

Configure IP on this interface? [yes]: 

IP address for this interface: 205.155.36.1 
Number of bits in subnet field [0]: 

Class C network is 205.155.36.0, 0 subnet bits; mask is 
255.255.255.0 

Configuring interface Ethernetl: 

Is this interface in use? [yes]: 

Configure IP on this interface? [yes]: 

IP address for this interface: 205.155.54.1 
Number of bits in subnet field [0]: 

Class C network is 205.155.54.0, 0 subnet bits; mask is 
255.255.255.0 

Configuring interface SerialO: 

Is this interface in use? [yes]: 

Configure IP on this interface? [yes]: NO 

Configuring interface Seriall: 

Is this interface in use? [no]: 

The following configuration command script was created: 

hostname mhs 

enable password XXXXX 

line vty 0 4 

password cisco 

no snmp-server 

j 

no decnet routing 
no appletalk routing 
no ipx routing 
no bridge 1 
ip routing 

I 

interface EthernetO 

ip address 205.155.36.1 255.255.255.0 
no mop enabled 

I 

interface Ethernetl 
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ip address 205.155.54.1 255.255.255.0 
no mop enabled 

j 

interface SerialO 
no ip address 
no mop enabled 

I 

interface Seriall 

shutdown 

no ip address 

I 

router igrp 11 
network 205.155.36.0 
network 205.155.54.0 

j 

end 

Use this configuration? [yes/no]: YES 
######[OK] 

Use the enabled mode 'configure' command to modify this 

configuration. 

mmhsttCONFIG T 

Enter configuration commands, one per line. End with 
CNTL/Z. 

mhs{config)#IP NftME-SERVER 205.155.43.2 
mhs(config)#INT S 0 
mhs{config-if)#ENCAP FRAME-RELAY 
mhs(config-if)#FRAME-RELAY LMI-TYPE ANSI 
mhs(config-if)#INT S 0.1 POINT-TO-POINT 

mhs(config-subif)#IP ADDR 198.189.239.22 255.255.255.252 

mhs(config-subif)#FRAME-RELAY INTERFACE-DLCI 906 BROADCAST 

mhs (config-stibif) #ROUTER IRPG 11 

mhs(config-router)#NETWORK 198.189.239.0 

mhs(config-router)#INT S 0.1 

mhs(config-subif)#DESCR ? LINE Up to 80 characters 
describing this interface 

mhs(config-subif)#descr MHS 2 MCOE CKT#50YBQQ275305-001, 
DLCI 906 

mhs(config-subif)#INT S 0.2 POINT-TO-POINT 
mhs{config-subif)#IP ADDR 198.189.239.106 255.255.255.252 
mhs(config-subif)#FRAME-RELAY INTERFACE-DLCI 806 BROADCAST 
mhs(config-subif)#INT S 0.2 
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mhs(config-subif)#DESCR ? LINE Up to 80 characters 
describing this interface 

mhs(config-subif)#descr MHS 2 CSU CKT#50YBQQ275305-001, DLCI 
806 

mhs (config-subif) 

mhs#%SYS-5-C0NFIG_I: Configured from console by console 
mhs#WR T 

#####Current configuration: 

I 

version 10.2 

I 

hostname mhs 

I 

enable password XXXXX 
! 

interface EthernetO 

ip address 205.155.36.1 255.255.255.0 
no mop enabled 

I 

Interface EthernetI 

ip address 205.155.54.1 255.255.255.0 
no mop enabled 

I 

interface SerialO 
no ip address 
encapsulation frame-relay 
frame-relay Imi-type ansi 

t 

interface SerialO.1 point-to-point 

description MHS 2 MCOE CKT#50YBQQ275305-001, DLCI 906 
ip address 198.189.239.22 255.255.255.252 
frame-relay interface-dlci 906 broadcast 

t 

interface SerialO.2 point-to-point 

description MHS 2 CSU CKT#50YBQQ275305-001, DLCI 806 
ip address 198.189.239.106 255.255.255.252 
frame-relay interface-dlci 806 broadcast 

I 

interface Seriall 
no ip address 
shutdown 

I 

router igrp 11 
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network 205.155.36.0 
network 205.155.54.0 
network 198.189.239.0 

I 

ip name-server 205.155.43.2 

I 

line con 0 
line aux 0 
line vty 0 4 
password cisco 
login 
! 

end 

inhs#WR######[OK] 

mhstEXIT 
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APPENDIX 1. MONTEREY BAYNET TOPOLOGY 


The following Figures 1.1 and 1.2 are a graphical depiction of the Monterey 
BayNet topology as designed in Chapter VI. The images were created by Jim Warner of 
the University of California Santa Cruz using a Computer Aided Design (CAD) program. 
Updates to the images are presently available for anonymous file transfer fi-om; 
ftp.ucsc.edu/MBay-net/ or monterey.kl2.ca.us/pub/the files are mmediMbaynet-Mont.ps 
and Mbaynet-SC.ps. The '.ps' file extension indicates that the file is stored in PostScript 
format and requires a PostScript viewer or printer to display. Corresponding Universal 
Resource Locators (URLs) for these diagrams are. 

• ftp://ftp. ucsc. edu/MBay-net/Mbaynet-Mont.ps. 

• ftp://ftp. ucsc. edu/MBay-net/Mbaynet-SC.ps. 

• ftp://monterey. kl2. ca. us/pub/Mbaynet-Mont.ps. 

• ftp://monterey. kl2. ca. us/pub/Mbaynet-SC.ps. 

The large circles in the diagram represent each of the sites. Each of them have a 
unique class C address from the 205.155.Y. block. The COEs are presented in the middle 
of the diagrams. At the top of each diagram is the Internet provider connection point, San 
Francisco State (SFSU) in Santa Cruz and CSU Monterey Bay (CSUMB) in Monterey. 
The heavy double line between SFSU and CSUMB represents the CSUnet backbone 
which connects each WAN (in addition to many other CSUnet sites) across the LATA 
boundary using Sprint as the primary long distance carrier. 

Each line connecting two large circles is a PVC. The PVC is mapped to PacBell's 
assigned DLCI indicated by the smaller circle on the line. At each end of the PVC are the 
IP addresses which allow DLCI mapping. The Santa Cruz DLCI IP addresses are all from 
the 198.189.240.Z block; Monterey from 198.189.239.Z. 

Note that the K-8 sites are forced to transit via the COEs in order to reach the 
Internet. High schools have direct access to the Internet provider without passing through 
the COE. See Chapter VI Section G for more details on this design decision. 
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Figure LI Monterey BayNet in Monterey County 
Available at flp://ucsc.edu/MBay-net/Mbaynet-Mont.ps. 
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Figure L2 Monterey BayNet in Santa Cruz County 
Available at ftp J/ucsc.edu/MBay-netMbaynet-SC.ps. 
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APPENDIX J. COMMITTED INFORMATION RATE (CIR) MATRIX 


Chapter VI describes the WAN topology design process. Tables J. 1 and J.2 are 
excerpted from PacBell's final work request inputs [Bellamy, 95], PacBell stated that a 
approximately two hundred percent over-commitment of the Frame Relay lines would be 
allowed [Bellamy, 95], The rate of over commitment is a negotiable value. Committed 
Information Rate (CIR) is PacBell's method of guaranteeing a worst case data exchange 
rate. This is of particular interest to customers who purchase full T-1 connectivity. On a 
full T-1 line Frame Relay the data is guaranteed to flow at the CIR and has the ability to 
"burst" to fiill T-1 speeds where the traffic permits. In the case of the Santa Cruz COE 
the CIR on DLCI190 is 512 Kbps. At any given moment the actual data exchange rate 
between SFSU and SCCOE will be some rate between 512 Kbps and 1.5 Mbps 
depending upon traffic conditions at the switch. The CIR for each site is of less critical 
importance. The Frame Relay service can not "burst" to higher levels on a partial T-1 line 
because the unused channels are physically blanked out. 

The total CIR in each LATA can be calculated by summing the CIR values and 
comparing the total with the physical line speed of the host. The sum of all Santa Cruz 
County Office of Education CIRs is 2.752 Mbps. Note that the CIR on DLCI 190 is only 
included once since this is physically the same PVC. Line speed at the Santa Cruz COE is 
1.5 Mbps. Comparison shows that the SCCOE line is 179.2% overcommitted. If every 
SCCOE site tried to connect to the SCCOE at the same time some sites would experience 
delays. Fortunately many sites have an alternate route to the Internet which does not pass 
through the SCCOE and thus reduces the opportunity for congestion at the SCCOE. 

Monterey County Office of Education has an even higher rate of over subscription. 
The total of all CIRs is 3.256. This yields a 220 percent oversubscription rate. Both 
counties are at the point where additional site connections will require the purchase of an 
additional T-1 line at the COE. 
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Location 



Santa Cruz County OflQce of 

Education 

1.536 

.512 

San Francisco State University 

1.536 

.512 

University of California Santa 

Cruz 

1.536 

.384 

Cabrillo College 

0.384 

.256 

Harbor High School 

0.128 

.128 

San Lorenzo Valley High 

0.128 

.128 

Soquel High School 

0.128 

.128 

Santa Cruz High School 

0.128 

.128 

Happy VaUey High School 

0.128 

.128 

Minte White Elementty School 

0.128 

.128 

Ohlone SchooiyPajaro Valley 

District 

0.128 

.128 

De La Veaga School 

0.056 

.056 

Branciforte Elementary School 

0.056 

.056 

Watsonville High School 

0.128 

.128 

Alianza School 

0.056 

.056 

Brook Knoll Elementary School 

0.056 

.056 

Rio Del Mar Elementary School 

0.056 

.056 

Valencia Elementary School 

0.056 

.056 

Aptos Ffigh School 

0.128 

.128 

Santa Cruz Garden Elementary 

0.056 

.056 

Del Mar Middle School 

0.056 

.056 


COE 

SFSU 

AddI 

Install 

DLCI 

DLCI 

DLCI 

Date 



03/13/95 


03/14/95 


230 03/15/95 


03/16/95 


03/24/95 


03/24/95 


03/30/95 


04/05/95 


04/10/95 


04/14/95 


04/20/95 


04/26/95 


05/01/95 


05/05/95 


05/05/95 


05/10/95 


05/16/95 


05/22/95 


05/24/95 


05/26/95 


12/95 


Table J.l Santa Cruz County OfiBce of Education Committed Information Rate (CIR) 
matrix excerpted from PacBell's final work request inputs [Bellamy, 95], 
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Location 

Line 

Speed 

CIR 

Mbps 

COE 

DLCI 

CSUMB 

DLCI 

Install 

Date 

1 

Monterey County Office of Education 

1.536 

.512 


890 

03/07/95 

2 

California State University Monterey Bay 

1.536 

.512 


890 

03/14/95 

3 

United States Naval Postgraduate School 

0.128 

.128 

902 

802 

03/09/95 

4 

Seaside High School Library 

0.128 

.128 

903 

803 

03/10/95 

5 

Monterey Bay Technology Education 

Center 

0.384 

.384 

904 

804 

03/22/95 

6 

Moss Landing Marine Laboratories 

0.128 

.128 

905 

805 

04/04/95 

7 

Monterey High School 

0.128 

.128 

906 

806 

04/03//95 

8 

North Monterey County High School 

0.128 

.128 

907 

807 

04/07/95 

9 

Monterey Bay National Marine Sanctuary^ 

0.128 

.128 

908 

808 

04/12/95 

10 

Monterey County Free Libraries 

0.128 

.128 

909 

809 

04/18/95 

11 

El Sausel Middle School 

0.128 

.128 

910 


04/24/95 

12 

Manzanita Elementary School 

0.128 

.128 

911 


05/24/95 

13 

La Mesa Elementary School 

0.128 

.128 

912 


05/03/95 

14 

Main Street School 

0.128 

.128 

913 


03/23/95 

15 

Del Rey Elementary School 

0.128 

.128 

914 


05/12/95 

16 

Cypress Continuation School 

0.128 

.128 

915 


05/18/95 

17 

Marshall Elementary School 

0.128 

.128 

916 


04/28/95 

18 

Mission Pari: Elementary School 

0.056 

.056 

917 


05/30/95 

19 

Instructional Media Center (IMC) 

0.128 

.128 

918 


06/05/95 

20 

Monterey Peninsula College Library 

0.128 

.128 

919 

819 

06/09/95 

21 

Monterey Institute for Research in 

Astronomy 

0.128 

.128 

920 

820 

6/14/95 

22 

Monterey Public Library 

0.128 

.128 

921 


6/16/95 


Table J.2 Monterey County Office of Education Committed Information Rate (CIR) 
matrix excerpted from PacBell's final work request inputs [Bellamy, 95], 









































































































































APPENDIX K. OBTAINING AN IP NETWORK NUMBER 


Chapter VI discussed the requirement for Internet Protocol (IP) network number 
registration with the InterNIC. The registration template is presented here for reference. 
The Monterey BayNet block of IP addresses were registered and issued by the Internet 
provider (CSUnet). The Universal Resource Locator (URL) for the latest copy of this 
registration template is ftp://rs.intemic.net/templates/intemet-number-template.txt 

[ templates/internet-number-template.txt ] [ 04/94 ] 

This form must be completed as part of the application 
process for obtaining an Internet Protocol (IP) Network 
Number. To obtain an Internet number, please provide the 
following information on-line, via electronic mail, to 
HOSTMASTER@INTERNIC.NET. If electronic mail is not 
available to you, please mail hardcopy to: 

Network Solutions 
InterNIC Registration Services 
505 Huntmar Park Drive 
Herndon, VA 22070 
-- OR -- 

FAX to (703) 742-4811 

Once Registration Services receives your completed 
application we will send you an acknowledgement, via 
electronic or postal mail. 

NOTE: This application is solely for obtaining a legitimate 
IP network number assignment. If you're interested in 
officially registering a domain please complete the domain 
application found in templates/domain-template.txt. If FTP 
is not available to you, please contact 

HOSTMASTER@INTERNIC.NET or phone the NIC at (800) 444-4345 
(703) 742-4777 for further assistance. 

YOUR APPLICATION MUST BE TYPED. 

1) If the network will be connected to the Internet, you 
must provide the name of the governmental sponsoring 
organization or commercial service provider, and the name, 
title, mailing address, phone niomber, net mailbox, and NIC 
Handle (if any) of the contact person (POC) at that 
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organization who has authorized the network connection. 

This person will serve as the POC for administrative and 
policy questions about authorization to be a part of the 
Internet. Examples of such sponsoring organizations are: 
DISA DNS, The National Science Foundation (NSF), or similar 
government, educational or commercial network service 
providers. 

NOTE: IF THE NETWORK WILL NEVER BE CONNECTED TO THE 
INTERNET, PLEASE UTILIZE THE ADDRESS SPACE RESERVED FOR NON- 
CONNECTED NETWORKS THAT IS SPECIFIED IN RFC 1597. IF YOU 
INTEND TO CONNECT THIS NETWORK TO THE INTERNET BUT HAVE NOT 
YET CHOSEN A SERVICE PROVIDER, LEAVE THIS SECTION BLANK, BUT 
INDICATE THE APPROXIMATE DATE OF YOUR INTERNET CONNECTION IN 
SECTION 9 OF THIS TEMPLATE. IF YOU INTEND TO CONNECT TO THE 
INTERNET AND HAVE ALREADY CHOSEN A PROVIDER, YOU ARE 
REQUIRED TO SUBMIT THIS REQUEST TO YOUR SERVICE PROVIDER FOR 
PROCESSING. SERVICE PROVIDERS ARE ALLOCATED BLOCKS OF 
ADDRESSES TO SUPPORT THE NETWORKING NEEDS OF THEIR 
CUSTOMERS. THIS PROCEDURE WILL ENSURE THAT THE NUMBER OF 
ENTRIES ADDED TO THE INTERNET ROUTING TABLES IS KEPT TO A 
MINIMUM, AND CIDR IS USED AS EFFICIENTLY AS POSSIBLE. THE 
ABOVE PROCEDURES PERTAIN EXCLUSIVELY TO REQUESTS FOR CLASS C 
ADDRESS(ES). 

la. Sponsoring Organization: 

lb. Contact name (Lastname, Firstname): 

l c. Contact title: 

l d. Mail Address : 

le. Phone : 

l f. Net mailbox : 

l g. NIC handle (if known): 

2) Provide the name, title, mailing address, phone number, 
and organization of the technical Point-of-Contact (POC). 

The on-line mailbox and NIC Handle (if any) of the technical 
POC should also be included. This is the POC for resolving 
technical problems associated with the network and for 
updating information about the network. The technical POC 
may also be responsible for hosts attached to this network. 

2a. NIC handle (if known): 

2b. Technical POC name (Lastname, Firstname): 


114 



2c. Technical POC title: 
2d. Mail address : 

2e. Phone : 

2f. Net Mailbox : 


3) Supply the SHORT mnemonic name for the network (up to 12 
characters). This is the name that will be used as an 
identifier in internet name and address tables. The only 
special character that may be used in a network name is a 
dash (-). PLEASE DO NOT USE PERIODS OR UNDERSCORES. The 
syntax XXXX.com and XXXX.net are not valid network naming 
conventions and should only be used when applying for a 
domain. 

3. Network name: 

4) Identify the geographic location of the network and the 
organization responsible for establishing the network. 

4a. Postal address for main/headquarters network 

site: 

4b. Name of Organization: 


5) Question #5 is for MILITARY or DOD requests, ONLY. 

If you require that this connected network be announced to 
the NSFNET please answer questions 5a, 5b, and 5c. IF THIS 
NETWORK WILL BE CONNECTED TO THE INTERNET VIA MILNET, THIS 
APPLICATION MUST BE SUBMITTED TO HOSTMASTER@MIC.DDN.MIL FOR 
REVIEW/PROCESSING. 

5a. Do you want MILNET to announce your network to the 
NSFNET? (Y/N): 

5b. Do you have an alternate connection, other than MILNET, 
to the NSFNET? (please state alternate connection if answer 
is yes): 

5c. If you've answered yes to 5b, please state if you would 
like the MILNET connection to act as a backup path to the 
NSFNET? (Y/N): 
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6) Estimate the size of the network to include the number of 
hosts and subnets/segments that will be supported by the 
network. A "host” is defined as any device (PC, printer 
etc.) that will be assigned an address from the host portion 
of the network nxamber. A host may also be characterized as a 
node or device. 

Host Information 


6a. Initially: 

6b. Within one year: 

6c. Within two years: 
6d. Within five years: 

Subnet/Segment Information 


6e. Initially: 

6f. Within one year: 

6g. Within two years: 

6h. Within five years: 

7) Unless a strong and convincing reason is presented, the 
network (if it qualifies at all) will be assigned a single 
class C network number. If a class C network number is not 
acceptable for your purposes, you are required to submit 
substantial, detailed justification in support of your 
requirements. 

7. Reason: 

8) Networks are characterized as being either Research, 
Educational, Government - Non Defense, or Commercial. Which 
type is this network? 

8. Type of network: 

9) What is the purpose of the network? 

9. Purpose: 

RECOMMENDED READING (available via anonymous FTP from 
DS.INTERNIC.NET (198.49.45.10), or call 1-800-444-4345 
option #1) 
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APPENDIX L. MONTEREY BAYNET DOMAIN NAME SERVICE 


The following Monterey BayNet sites have domain name service (DNS) entries as 
indicated below. Most individual school sites do not presently operate an Internet server. 
In the interim these DNS entries Avill be linked to their respective county office of 
education (205.155.8.2 and 205.155.43.2). When the site has established an Internet 
server the DNS will be corrected to reflect the IP address of that server. The registration 
process was performed as per Appendix M. 

In designing the names balance needs to be found between clear descriptions and 
unclear acronyms. Note that DNS names are not case sensitive. Variations on a theme 
with upper and lower case letter will not work. Another consideration discovered in 
Monterey BayNet is that some seemingly appropriate acronyms have inappropriate 
connotations in a foreign language. In a largely bi-lingual population these considerations 
are vital. The final approval of DNS entries must reside with the site residents. 

SANTA CRUZ COUNTY LANs & DNS 

Ethernet Site DNS Name 

205.155.1 Harbor High School harborhs.santacruz.kl2.ca ns 

205.155.2 San Lorenzo Valley High slvhs.santacruz.kl2.ca.us 

205.155.3 Watsonville High School whs.santacruz.kl2.ca.us 

205.155.4 Aptos IBgh School aptoshs.santacruz.kl2.ca.us 

205.155.5 Santa Cruz High School santacruzhs.santacruz.kl2.ca.us 

205.155.6 Soquel High School soquelhs.santacruz.kl2.ca.us 

205.155.7 Cabrillo College cabrillo.cc.ca.us 

205.155.8 Santa Cruz County Office 

ofEducation sccoe.santacruz.kl2.ca.us 

205.155.9 Nfintie White Elementary mw.santacruz.kl2.ca.us 

205.155.10 Alianza Elementary alianza.santacruz.kl2.ca.us 

205.155.11 Branciforte Elementary b40elem.santacruz.kl2.ca.us 

205.155.12 Santa Cruz Garden Elem scg.santacruz.kl2.ca.us 

205.155.13 Brook Knoll Elementary brknoll.santacruz.kl2.ca.us 

205.155.14 Ohlone School ohlone.santacruz.kl2.ca.us 

205.155.15 De La Veaga School delave.santacruz.kl2.ca.us 

205.155.16 Del Mar Middle School delmar.santacruz.kl2.ca.us 

205.155.17 Valencia Elementary Valencia.santacruz.kl2.ca.us 

205.155.18 Rio Del Mar Elementary riodelmar.santacruz.kl2.ca.us 

205.155.19 Happy Valley School happyvalley.santacruz.kl2.ca.us 
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MONTEREY COUNTY LANs & DNS 


Ethernet 

205.155.32 

205.155.33 

205.155.34 

205.155.35 

205.155.36 

205.155.37 

205.155.38 

205.155.39 

205.155.40 

205.155.41 

205.155.42 

205.155.43 

205.155.44 

205.155.45 

205.155.46 

205.155.47 

205.155.48 

205.155.49 

205.155.50 

205.155.51 

205.155.52 


205.155.53 

205.155.54 

205.155.55 


Site 

Naval Postgraduate School 
Education Access Gateway 
Seaside High School 
Monterey Bay Technology 
Education Center 
Moss Landing Marine Lab 
Monterey High School 
North Monterey County 
High School 
Monterey Bay National 
Marine Sanctuary 
Monterey County Free 
Libraries 

Monterey Peninsula 
College Library 
Monterey Institute for 
Research in Astronomy 
Monterey Public Library 
Monterey County 
Office of Education 
El Sausel Middle School 
Manzanita Elementary 
La Mesa Elementary 
Main Street School 
Del Rey Elementary 
Cypress Continuation 
Marshall Elementary 
(lower campus) 

Mission Park Elementary 
Monterey Peninsula Unified 
School District Instructional 
Media Center 

Monterey County Office of 
Education (secure) 
Monterey Academy of 
Oceanographic Science 
Fitch Middle School 


DNS Name 


edac.nps.navy.mil 

shs.monterey.kl2.ca.us 

mbtec.monterey.kl 2. ca.us 
mlml.calstate.edu 
nihs.monterey.kl2.ca.us 

nmhs. monterey. k 12. ca.us 

mbnms.nos.noaa.gov 

mcfl. monterey. lib. ca. us 

mpc.cc.ca.us 

mira.org 

monterey.lib.ca.us 

bill.monterey. k 12. ca.us 
elsaus. monterey .k 12. ca.us 
mz. monterey. k 12. ca. us 
Imesa. monterey .k 12. ca. us 
mainst. monterey.k 12. ca.us 
drey, monterey. k 12. ca.us 
cyp. monterey. k 12. ca. us 

marsh, monterey.k 12. ca.us 
mnpk. monterey. k 12. ca. us 


imc.monterey.kl2.ca.us 

mcoe. monterey .k 12. ca.us 

maos.monterey.kl2.ca.us 

fitch.monterey.kl2.ca.us 
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APPENDIX M. INSTRUCTIONS FOR THE US DOMAIN TEMPLATE 

A. SUMMARY 

Chapter VI discussed the requirement for domain registration. Monterey BayNet 
registered with CSUnet, the Internet provider. Portions of the registration template are 
presented here for reference and to compare with the completed Monterey BayNet 
registration forms which follow. The Universal Resource Locator (URL) for the latest 
copy of the registration form is ftp://rs.intemic.net/templates/domain-template.txt. 

B. TEMPLATE 

INSTRUCTIONS FOR THE US DOMAIN TEMPLATE [1/95] 

(Do not use this template for: COM, EDU, NET, ORG, GOV)* 
************************************************************ 

To register a host in the US domain, the US Domain Template 
must be sent to the US Domain Registrar (US-Domain@ISI.EDU) 
or contact of a delegated zone. 

Email: US-Domain@ISI. EDU 

Fax: 310-823-6714 

Phone: 310-822-1511 
To: US Domain Registrar 

USC/Information Sciences Institute 

4676 Admiralty Way, Marina del Rey, CA 90292 

(1) PLEASE SPECIFY WHETHER THIS IS A NEW APPLICATION, 
MODIFICATION TO AN EXISTING REGISTRATION, OR DELETION. 

(2) THE NAME OF THE DOMAIN. This is the name that will be 
* used in tables and lists associating the domain with the 

domain server addresses. 


TABLE: US DOMAIN NAMING STRUCTURE 


<host>.<locality>.<state-code>.US = locality based names 
<host>.CL<locality>.<state-code>.US = locality; city gov. agency 
<host>.CO.<locality>.<state-code>.US= locality; county gov. agency 
<school>.<district>.K12.<state-code>.US = K thru 12th grade 
<school>.PVT.K12.<state-code>.US = private K thru 12th grade 
<school>.<locality>.<state-code>.US = locality opt;for PVT Sch 
<school>.CC.<state-code>.US = community colleges 
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<school>.TEC <state-code>.US = technical or vocational schools 
<Iibrary-nanie>.LIB.<state-code>.US = libraries (Cl, CO, State,PVT) 
<State-agency>.STATE.<state-code>.US = state government agencies 
<org-name>.GEN.<state-code>.US = statewide assoc,clubs,BBs's 
<org-name>.MUS.<state-code>.US = museums 
<org-name>.COG <state-code>.US = councils of governments 
<org-name>.DST <state-code>.US = regional agencies or districts (not gov't & larger 
than city or county) 

<federal-agency>.FED.US = federal government agencies 

<org-name>.DNI.US = distributed national institutes (research, educational, cultural) 
<org-name>.ISA.US = interstate authority (joint gov't authorities - multistate) 

Domain Name Example: networthy.santa-clara.ca.us 

(3) THE NAME OF THE ENTITY REPRESENTED, THAT IS, 
ORGANIZATION BEING NAMED. For example: The Networthy 
Corporation, not the name of the Network Service Provider or 
organization submitting the request. 

(4) PLEASE DESCRIBE THE DOMAIN BRIEFLY. 

For exait^le: The Networthy Corporation is a consulting 
organization of people working with UNIX and the C language 
in an electronic networking environment. It sponsors two 
technical conferences annually and distributes a bimonthly 
newsletter. 

(5) THE DATE YOU EXPECT THE DOMAIN TO BE FULLY OPERATIONAL. 
For every registration, we need both the administrative 

and the technical contacts of a domain (questions 6 & 7) and 
we MUST have ^ network mailbox for each. If you have a NIC 
handle (a unique NIC database identifier) please enter it. 
(If you don't know what a NIC handle is leave it blank). 

Also the title, mailing address, phone number, organization, 
and network mailbox. 

(6) THE NAME OF THE ADMINISTRATIVE HEAD OF THE 
"ORGANIZATION". The administrator is the contact point for 
administrative and policy questions about the domain. The 
Domain administrator should work closely with the personnel 
he has designated as the "technical contact" for his domain. 
In this example the Domain Administraror would be the 
Administrator of the Networty Corporation, not the 
Administrator of the organization running the nameserver 
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(unless it is the same person). 


(7) THE NAME OF THE TECHNICAL AND ZONE CONTACT. The 
technical and zone contact handles the technical aspects of 
maintaining the domain's name server and resolver software, 
and database files. He keeps the name server running. More 
than likely, this person would be the technical contact 
running the primary nameserver. 

PLEASE READ: There are several types of registrations: 

(a) Delegation (i.e., a portion of the US Domain name 
space is given to an organization running nameservers to 
support that branch; For example, K12.TX.US, for all K12 
schools in Texas). For (a) answer questions 8 and 9. 

(b) Direct Registration of an IP Host. For (b) answer 
question 10. 

(c) Direct Registration of a non-IP Host. For (c) answer 
question 11 and 12. 

************************************************************ 
QUESTIONS FOR DELEGATIONS 

(8) PRIMARY SERVER Information. It is required to supply 
both the Contact information as well as hardware/software 
information of the primary nameserver. 

(9) * SECONDARY SERVER Information. It is required to supply 
the hardware and software information of all secondary 
nameservers. Domains must provide at least two independent 
servers that provide the domain service for translating 
names to addresses for hosts in this domain. If you are 
applying for a domain and a network number assignment 
simultaneously and a host on your proposed network will be 
used as a server for the domain, you must wait until you 
receive your network number assigment and have given the 
server(s) a net-address before sending in the domain 
application. Establishing the servers in physically separate 
locations and on different PSNs and/or networks is strongly 
recommended. 
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NOTE: For those applicants not able to run nameservers, or 
for non-IP hosts the Name Server information is not 
applicable. (See #10 and #11). 


QUESTION FOR DIRECT IP HOSTS (If you answered 8&9 do not 
answer 10,11,12). 


(10) WHAT DOMAIN NAME SYSTEM (DNS) RESOURCE RECORDS (RR) AND 
VALUES ARE TO BE ENTERED FOR YOUR IP HOST (MUST HAVE AN A 
RECORD). 


Example: RRs for an INTERNET hosts. 


(a) DOMAIN NAME (required)... 

(b) IP ADDRESS (required).... 

(C) HARDWARE (opt). 

(d) OPERATING SYS (opt). 

(e) WKS (opt). 

(ftp) 

(f) MX (opt). 


Networthy.Santa-Clara.CA.US. 
A 128.9.3.123 
SUN-3/no 
UNIX 

128.9.3.123. UDP (tftp) TCP 
10 RELAY.ISI.EDU. 


It is your responsibility to see that an IN-ADDR pointer 
record is entered in the DNS database. (For internet hosts 
only). Contact the administrator of the IP network your 
host is on to have this done. The US Domain administration 
does not administer the network and cannot make these 
entries in the DNS database. 


QUESTIONS FOR NON-IP HOSTS (such as UUCP). 


Many applicants have hosts in the UUCP world. Some are one 
hop away, some two and three hops away from their "Internet 
Forwarder", this is acceptable. What is inportant is 
getting an Internet host to be your forwarder. If you do 
not already have an Internet forwarder, there are several 
businesses that provide this service for a fee, (see RFC 
1359 - Connecting to the Internet What Connecting 
Institutions Should Anticipate, ACM SIGUCCS, August 1992). 
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Sometimes local colleges in your area are already on the 
Internet and may be willing to act as an Internet Forwarder. 
You would need to work this out with the systems 
administrator. We cannot make these arrangements for you. 

(11) INTEENET FORWARDING HOST INFORMATION 

(lla) What is the name of your Internet forwarding host? 

For example: The host Yacht-Club.MDR.CA.US uses UUCP to 
connect to RELAY.ISI.EDU which is an Internet host, (i.e., 
RELAY.ISI.EDU is the forwarding host). 

(llb) What is the name of your contact person at fowarding 
host? The Administrator of RELAY.ISI.EDU must agree to be 
the forwarding host for Yacht-Club.MDR.CA.US, and the 
forwarding host must know a delivery method and route to 
Networthy. No double MXing. 

(llc) What is the mailbox of your contact? What is the 
mailbox of the administrator of the forwarding host. 

Example: Contact Name.: John Smith 

Contact Email.: js@RELAY.ISI.EDU 

(12) WHAT DOMAIN NAME SYSTEM (DNS) RESOURCE RECORDS (RR) AND 
VALUES ARE TO BE ENTERED FOR YOUR NON-IP HOST. 


Example: RRs for a NON-IP host (uucp). 


(a) DOMAIN NAME (required).: Yacht-Club.MDR.CA.US. 

(b) HARDWARE (opt)...: SUN-3/110 

(C) OPERATING SYS (opt).: UNIX 

(d) MX (required).: 10 RELAY.ISI.EDU. 


* NOTE: All K12 schools, community colleges/technical 
schools, state and local governmentt agencies are required 
to register -under the US domain. Only four year universities 
are allowed to register under EDU and only federal agencies 
are allowed voider GOV. (See RFC 1480, "The US Domain" and 
RFC 1591, "The Domain Name System Structure and Delegation" 
for details. 
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C. COMPLETED DNS REGISTRATION FORM FROM THE SANTA CRUZ 
COUNTY OFFICE OF EDUCATION 

1. REGISTRATION TYPE 

(N)ew (M)odify (D)elete..: N 

2. * FULLY-QUALIFIED DOMAIN NAME: santacruz.kl2.ca.us. 


3. ORGANIZATION INFORMATION 

3a. Organization Name.: Santa Cruz County Office of 

Education 

3b. Address Line 1.: 809 H Bay Avenue 

3b. Address Line 2.: 

3c. City...: Capitola 

3d. State.: Ca 

3e. Zip/Code.: 95010 

4. DESCRIPTION OF ORG/DOMAIN: The public schools in 

Santa Cruz County 

5. Date Operational.: April 15, 1995 


6. ADMINISTRATIVE CONTACT 
6a. NIChandle (if known).. 

6b. Whole Name. 

6c. Organization Name. 

6d. Address Line 1. 

6d. Address Line 2. 

6e. City. 

6f. State. 

6g. Zip/Code. 

6h.* Voice Phone. 

6i.* Electronic Mailbox.... 


OF ORG/DOMAIN 
Rowland Baker 

Santa Cruz County Office of 

Education 

809 H Bay Avenue 

Capitola 

Ca 

95010 

408-476-5346 
rowbake@telis.org 


7. TECHNICAL AND ZONE CONTACT 
7a. NIChandle (if known)..: 

7b. Whole Name.: Lucas Fletcher 

7c. Organization Name.: Santa Cruz County Office of 

Education 

7d. Address Line 1.: 809 H Bay Avenue 

7d. Address Line 2.: 

7e. City.: Capitola 

7f. State.: Ca 

7g. Zip/Code.: 95010 

7h.* Voice Phone.: 408-476-7140 

7i.* Electronic Mailbox....:dnsmgr@sccoe.santacruz.kl2.ca.us 


126 
































FILL OUT QUESTION 8 AND 9 FOR DELEGATIONS ONLY (i.e those 
organizations running nameservers for a branch of the 
US Domain namespace, for example: kI2.<state>.us). 

8. PRIMZ^RY SERVER: HOSTNAME, NETADDRESS 


NIChandle (if known).. 

Whole Name. 

Organization Name. 


8d. 

8d. 

8e. 

8f. 

8g. 

8h.* 

8i.* 

8j . 

8k.* 

81.* 

8m. * 


Address Line 1.... . 
Address Line 2.... 

City. 

State. 

Zip/Code. 

Voice Phone. 

Electronic Mailbox 

Hostname. 

IP Address . 

HARDWARE. 

OPERATING SYS. 


Lucas Fletcher 

Santa Cruz County Office of 

Education 

809 H Bay Avenue 

Capitola 

Ca 

95010 

408-476-7140 

dnsmgrgsccoe.santacruz.kl2.ca.us 
ns.santacruz.kl2.ca.us 
205.155.8.2 
Sun 

Solaris 2.4 


9. * SECONDARY SERVER: HOSTNAME, NETADDRESS 


9a.* Hostname.. 

9b.* IP Address..., 

9c. * HARDWARE.. 

9d.* OPERATING SYS, 


morris.ucsc.edu 

128.114.1.6 

Sun 

SunOS 4.1.3U 


D. COMPLETED DNS REGISTRATION FORM FROM THE MONTEREY 
COUNTY OFFICE OF EDUCATION 

1. REGISTRATION TYPE 

(N)ew (M)odify (D)elete..: N 

2. * FULLY-QUALIFIED DOMAIN NAME: monterey.kl2.ca.US. 

3. ORGANIZATION INFORMATION 

3a. Organization Name.: Monterey County Office of 

Education 

3b. Address Line 1.: 901 Blanco Circle 

3b. Address Line 2.: 

3c. City.: Salinas 

3d. State.: Ca 

3e. Zip/Code.: 93912 

4. DESCRIPTION OF ORG/DOMAIN: The Monterey County 

Office of Education is a 
non-profit California 
County government agency 
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5. 


Date Operational.: April 5, 1995 

6. ADMINISTRATIVE CONTACT OF ORG/DOMAIN 
6a. NIChandle (if known)..: 

6b. Whole Name.: Michael Ottmar 

6c. Organization Name.: Monterey County Office 

of Education 

6d. Address Line 1.: 901 Blanco Circle 

6d. Address Line 2.: 

6e. City.: Salinas 

6f. State.; Ca 

6g. Zip/Code.: 93912 

6h.* Voice Phone.: 408-755-0308 

6i.* Electronic Mailbox....: mottmar@mcoe.monterey.kl2.ca.us 


7. 

7a. 

TECHNICAL AND ZONE CONTACT 

NIChandle (if known)..: 

7b. 

Whole Name.: 

Michael Mellon 

7c. 

Organization Name.: 

Monterey County Office of 
Education 

7d. 

7d. 

Address Line 1.: 

Address Line 2.: 

901 Blanco Circle 

7e. 

City...: 

Salinas 

If. 

State.: 

Ca 

7g. 

Zip/Code.: 

93912 


7h.* Voice Phone.: 408-755-0383 

7i.* Electronic Mailbox....: mmellon@mcoe.monterey.kl2.ca.us 

FILL OUT QUESTION 8 AND 9 FOR DELEGATIONS ONLY (i.e those 
organizations running nameservers for a branch of the 
US Domain namespace, for example: kl2.<state>.us). 


8. PRIMARY SERVER: HOSTNAME, NETADDRESS 


8a. NIChandle (if known)..: 

8b. Whole Name.: 

8c. Organization Name.: 

8d. Address Line 1.: 

8d. Address Line 2.: 

8e. City.: 

8f. State.: 

8g. Zip/Code.: 

8h.* Voice Phone.: 

8i.* Electronic Mailbox....: 

8 j . Hostname.: 

8k.* IP Address .: 

81.* HARDWARE.: 

8m.* OPERATING SYS.: 


Michael Mellon 

Monterey County Office of 

Education 

901 Blanco Circle 

Salinas 

Ca 

93912 

408-755-0383 

mmellon@mcoe.monterey.kl2.ca.us 
bill.monterey.kl2.ca.us 
205.155.43.2 
Sun 

Solaris 2.4 
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9. * SECONDARY SERVER: HOSTNAME, NETADDRESS 
9a.* Hostname.: morris.ucsc.edu 


9b.* IP Address... 

9c.* HARDWARE. 

9d.* OPERATING SYS 


128.114.1.6 

Sun 

SunOS 4.1.3u 
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APPENDIX N. REGISTERING FOR AN AUTONOMOUS SYSTEM NUMBER 


Chapter VI discussed the requirement for Autonomous System (AS) registration 
with the InterNIC. Monterey BayNet is has not implemented any gateways and is not 
required to register as an AS at this time. Excerpts from the registration template are 
presented here for reference. The Universal Resource Locator (URL) for the latest copy 
of this registration template is ftp://rs.intemic.net/templates/asn-template.txt 

[ netinfo/asn-template.txt ] [ 09/94 ] 

Registering for an Autonomous System Number implies that you 
plan to implement one or more gateways and use them to 
connect networks in the Internet. Please provide us with 
further details about your plans, and with information about 
the administrative authority you have for participating in 
the Internet. 

It is strongly advised that you follow the development of 
inter-autonomous systems protocols in the lAB task forces. 

To obtain an Autonomous System Number the following 
information must be provided: 

1) The name, title, mailing address, phone number, and 
organization of the administrative head of the organization. 

2) The name, title, mailing address, phone number, and 
organization of the technical contact. 

3) The name of the autonomous system (up to 12 characters). 
This is the name that will be used in tables and lists 
associating autonomous systems and numbers. 

4) A description of the gateway that implements the inter- 
autonomous system protocol for interaction with other 
autonomous systems. Currently the exterior gateway protocol 
(EGP) is being used for this purpose (RFC 904). This 
gateway should comply with RFC 1009, Requirements for 
Internet Gateways. 

5) A description of the gateway hardware, including CPU and 
interfaces. 


131 



6) A description of the gateway software, including 
operating system and languages. 

7) The deployment schedule for the autonomous system. 

(a) initially, 

(b) within one year, 

(c) two years, and 

(d) five years. 

8) What networks will be interconnected by these gateways? 
What are the internet addresses of each gateway? 

RECOMMENDED READING (From Registration Services) 

Mills, D.L. Exterior Gateway Protocol Formal Specification. 
1984 April; RFC 904. 30 p. {RS.INTERNIC.NET POLICY 

RFC904.TXT). 

Braden, R.T.; Postel, J.B. Requirements for Internet 
Gateways. 1987 June; RFC 1009. 55 p. (RS.INTERNIC.NET 

POLICY RFC1009.TXT). 
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APPENDIX O. MACTCP CONFIGURATION 


MacTCP is the proprietary software being used in Monterey BayNet to allow Macintosh 
products to "talk" Internet Protocol (IP). The easiest way to to obtain MacTCP is 
through the purchase of The Internet Starter Kit for the Macintosh (currently $29.95) at 
many bookstores [Engst, 94]. Version 2.0.6 comes bundled with operating system 7.5. A 
version 2.0.4 upgrade to 2.0.6 "patch" is available at ftp://seeding.apple.com/mactcp/. 
Monterey BayNet recommends using the MacTCP version that came bundled with system 
7.5 or version 2.0.4. The "patched" version 2.0.6 is NOT recommended because it has 
been found to cause more errors than it fixes. 

To Install MacTCP drag the MacTCP icon onto the system folder. Open MacTCP and 
immediately click on the "More..." button to expose the screen below. 

Configure as below substituting appropriate IP addresses: 

Monterey Domain Name/IP Address= nionterey.kl2.ca.us 205.155.43.2 
Santa Cruz Domain Name/IP Address = santacruz.kl2.ca.us 205.155.8.2 
Gateway is the site router address - 205.155.y.l 

In the IP Address box change only the class do not attempt to modify the net, subnet or 
node. When complete click OK to bring back the opening screen. 
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Input the IP address of the specific machine you are configuring. A good practice is to 
write the IP address and name of the terminal on the face of the terminal. This will avoid 
future confusion if the settings of MacTCP are lost. Select Ethernet by clicking on it. 



Close MacTCP. You will be advised to restart the machine in order for the changes to 
take effect. Before restarting verify that AppleTalk is active in the Chooser by selecting 
"active" as shown below. 
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Verify that EtherTalk is selected in the Network control panel. The Macintosh is now 
configured for proper operation in future sessions. Restart your Macintosh, test and 
enjoy! 
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APPENDIX P. WINDOWS TRUMPET WINSOCK PACKET DRIVER 

CONFIGURATION 


Install Trumpet Winsock as a packet driver in accordance with the install.txt file provided 
with the software. Trumpet Winsock can be obtained at the following URL: 
ftp://ftp.cica.indiam.edu/ftp/pub/pc/win3/winsock/twsk20b.zip. 


The following configuration parameters have been tested in Monterey BayNet sites: 

IP address: The IP address of the machine. (205.155.y. 1 and 205.155.y.2 are the router 
and WWW server. 205.155.y.3 is the first terminal at the site, 205.155.y.254 the last). It is 
good practice to write the IP address on the face of the device. 

Netmask: 255.255.255.0 

Default Gateway: The site router IP address. 205.155.y.l 
Name server: Monterey =205.155.43.2 
Santa Cruz = 205.155.8.2 
Domain suffix: Monterey = monterey.kl2.ca.us 
Santa Cruz = scruz.kl2.ca.us 

Packet Vector: Deftiult value of 00. The value must reflect the packet driver vector 
where the packet driver is installed. The number is expressed in hexadecimal without the 
leading "Ox". 


MTU: 1500 is maximum and recommended. 

TCP RWIN: Defaults to 4096 but can be larger. 

TCP MSS: Use the default of 1460. 

The Internal SLIP and PPP check boxes should NOT be checked. 


Network Configuration 


IP address 
Netmask 
Name server 
Domain Suffix 
Packet vector 


205.155.33.7 


255.255.255.0 


205.155.43.2 


Default Gateway 
Time server 


205.155.33.1 


monterey.kl 2.ca.us 


00 


MTU 


Demand Load Timeout (secs) 


1500 


TCP RWIN 


4096 h-CPMSS 


TCP RTO MAX 


1460 


D Internal SUP G Internal PPP 


SUP Port 
Baud Rate 



Q Hardv.'ais Harsdsliake 
D Van Jacobson CSLfP compression 


Online Status Detection 

® fJaiTje 

O DCD |RLSO| checfe 
O DSR check 





















APPENDIX Q. ACRONYMS 


ADN 

Advanced Digital Network 

AIF 

Audio Interchange Format 

ANSI 

American National Standards Institute 

ATM 

Asynchronous Transfer Mode 

AU 

Audio (file name extension) 

AUI 

Attachment Unit Interface 

BMP 

Bitmap Picture (file name extension) 

BRI 

Basic Rate Interface 

CalREN 

California Research and Education Network 

CIR 

Committed Information Rate 

CNE 

Certified NetWare Engineer 

COE 

County Office of Education 

CSMA/CD 

Carrier Sense Multiple Access/with Collision Detection 

csu 

Channel Service Unit 

CTS 

Clear To Send 

DLCI 

Data Link Control Identifier 

DLL 

Dynamic Link Library 

DoD 

Department of Defense 

DoN 

Department of the Navy 

DS 

Data Send 

DSU 

Digital Service Unit 

EIA 

Electronic Industries Association 

.EXE 

Executable (file name extension) 

FDDI 

Fiber Distributed Data Interface 

FTP 

File Transfer Protocol 

Gb 

Gigabit 

GB 

Gigab)de 

GIF 

Graphics Interchange Format (file name extension) 

GUI 

Graphical User Interface 

•gz 

Gzip compressed file (file name extension) 

HiCap 

Hi^ Capacity Digital Service 

.HQX 

BinHexed (file name extension) 

HTML 

HyperText Markup Language 

HTTP 

HyperText Transport Protocol 

Ula 

Initiative for Information Infrastructure and Linkage Applications 

IEEE 

Institute of Electrical and Electronics Engineers 

IETF 

Internet Engineering Task Force 

IGP 

Interior Gateway Protocol 

IGRP 

Interior Gateway Routing Protocol 

IMAP 

Internet Message Access Protocol 

IP 

Internet Protocol 
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IPX Internetwork Packet exchange 

ISDN Integrated Services Digital Network 

JFff JPEG File Interchange Format 

JPEG Joint Photographic Experts Group 

K-12 Kindergarten through 12th Grade 

KB Kilobyte 

KBPS Kilobits Per Second 

LAN Local Area Network 

LATA Local Access Transport Area 

LED Light-Emitting Diode 

LMI Local Management Interface 

LZW Lempel-Ziv-Walsh 

MAC Medium Access Control 

.MAC MacPaint (file name extension) 

MAOS Monterey Academy of Oceanographic Science 

MBARI Monterey Bay Aquarium Research Institute 

MBone Multicast Backbone 

Mbps Megabits per second 

MB ReEF Monterey Bay Regional Education Futures 
MB TEC Monterey Bay Technology Education Center 

MCOE Monterey County Office of Education 

MPEG Moving Picture Experts Group 

MPOE Minimum Point of Entry 

NCC Network Control Center 

NCSA National Center for Supercomputing Applications 

NESC National Electrical Safety Code 

NIC Network Information Center / Network Interface Card 

Nil National Information Infi-astructure 

NIU Network Interface Unit 

NNTP Network News Transfer Protocol 

NOAA National Oceanic and Atmospheric Administration 

NOC Network Operations Center 

NPS Naval Postgraduate School 

NRC National Research Council 

OSPF Open Shortest Path First 

.PDF Printer Description File (file name extension) 

PICT Picture file 

POP Post Office Protocol 

PPP Point-to-Point Protocol 

PRI Primary Rate Interface 

.PS PostScript f(file name extension) 

PVC Permanent Virtual Circuit 

REINAS Real-Time Environmental Information Network and Analysis System 
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RFC 

Request For Comments (See bibliography) 

RIP 

Routing Information Protocol 

RJ 

Registered Jack 

RLE 

Run Length Encoded 

SCCOE 

Santa Cruz County Office of Education 

SFSU 

San Francisco State University 

SGML 

Standard Generalized Markup Language 

SPF 

Shortest Path First 

■tar 

Tape ARchive (file name extension) 

•tar.Z 

Compressed Tape ARchived file (file name extension) 

TA 

Terminal Adapter 

TCP/IP 

Transmission Control Protocol/Intemet Protocol 

TD 

Transmit Data 

TIA 

Telecommunications Industry Association 

TSU 

T1 Service Unit (Adtran) 

T-1 

Carrier bandwidth of 1.544 Mbps (2.048 Mbps in Europe) 

ucsc 

University of California Santa Cruz 

UPS 

Uninterruptible Power Supply 

URL 

Uniform Resource Locator 

UTP 

Unshielded Twisted-Pair 

UU 

Uuencode/Uudecode 

WWW 

World-Wide Web 

.z 

Packed file (file name extension) 

Z 

Compressed file (file name extension) 

ZIP 

Compressed File (file name extension) 
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